Jimmy Maher (maher@filfre.net)

The Digital Antiquarian
Volume 1: 1966-1979

Read the blog
http://www.filfre.net

Support the blog on Patreon
https://www.patreon.com/DigitalAntiquarian

This eBook was converted on
December 20th, 2015

Design and conversion for eBooks by
Richard Lindner (rlindner81@gmail.com)

On the Trail of the Oregon Trail, Part 1
March 27, 2011

I recently got a copy of 1001 Video Games You Must Play Before You Die. It’s not really a very good book, for reasons that are interesting on their own and that I hope to talk about in another post very soon. Right now, though, I want to talk about the very first entry in the book, on The Oregon Trail, because that entry sent me down a rabbit hole from which I have only just emerged, blinking and reconsidering the history of interactive narrative.

If you’re of a certain age and nationality (i.e., mine), you almost certainly know The Oregon Trail. From the early 1980s until well into the 1990s virtually every public school in America seemed to have at least a few Apple IIs off in a corner somewhere, and one of the titles available on them was guaranteed to be this little educational game which placed the player in the role of a would-be settler setting off from Missouri on the long journey to the Oregon Territory. Those versions communicated mostly in text, but they spiced up their presentation with lots of colorful graphics, and were appealing enough to become favorites among students then and to still be nostalgically remembered by millions today. In fact, I just learned that there is now a Facebook app of the game.

What’s not often realized is that even when it first arrived on the Apple II The Oregon Trail was already a very old game. That’s why it’s the first entry in the chronologically arranged 1001 Video Games. (Actually, the fact that they got this date right is kind of surprising, because there are a heck of a lot of others that they got wrong. But I promised not to kvetch about the book right now…) It was in fact first written in 1971 by three educators at Carleton College, a small liberal arts college in Northfield, Minnesota. Don Rawitsch, Bill Heinemann — no relation to the “Burger Bill” Heineman who worked on The Bard’s Tale series among other games — and Paul Dillenberger wrote the game in BASIC on an HP-2100 series minicomputer.

When I was writing my history of IF, I named two programs as the most important predecessors to the landmark Adventure (1976-77): Joseph Weizenbaum’s Eliza (1966), which first deployed the basic system of IF interaction (albeit in the context of an elaborate parlor trick rather than a game) and Gregory Yob’s Hunt the Wumpus, a simple game in which the player moves from room to room in a maze while attempting to avoid and eventually kill the eponymous Wumpus. The Oregon Trail makes me think that there should be a third entry on that list.

Let’s consider the state, such as it was, of interactive narrative in 1971. While there had been experiments with interactive storytelling before in the mystery genre, examples of the form were pretty thin on the ground. Edward Packard had already tried to get the first of what would become the Choose Your Own Adventure line of books published, but had been rejected by every publisher he had turned to, and would have to wait years more to see his idea in print. A group of scruffy wargamers in Wisconsin were toying around with the systems that would become Dungeons and Dragons, but, again, their work was years from publication. Wargames and other simulation games certainly had an experiential component, implicitly inviting their players to imagine the events they simulated unfolding in their imagination, but said events unfolded from the perspective of a god on high rather than that of an individual player in storyworld. In the world of computers, there was some ongoing work into computer-generated narrative among artificial intelligence researchers, but these were not really interactive narrative, but rather self-contained stories that the computer generated beforehand based on a set of input data and played out for an audience.

Yet The Oregon Trail opens by telling us, “Your family of five will cover the 2040 mile Oregon Trail in 5-6 months – if you make it alive. You had saved $900 to spend for the trip, and you’ve just paid $200 for a wagon.” It’s dropping us into a storyworld, and inviting us to take a role there and decide what happens next. Was there a computer program before this that so obviously wanted to make a story with (as opposed to for) us? I don’t know of it if there was.

So, I set off on a quixotic quest to experience The Oregon Trail in as close to its original form as I could manage. More on that next time.

On the Trail of the Oregon Trail, Part 2
March 28, 2011

I mentioned last time around that the original Oregon Trail was written on an HP-2100 series minicomputer. That’s a pretty interesting topic in itself.

HP’s first computer line, the 2100 series could be equipped with a number of possible operating system. One of the most common, and the one under which The Oregon Trail was written, was called HP Time-Shared BASIC. This system was very unique in its time, and perhaps even visionary. Rather than placing the user in the command-line driven environment typical of virtually all other OSs of the period, Time-Shared BASIC, true to its name, dropped the user after login into an interactive BASIC environment. Not only could she write programs here using BASIC, but all of her other immediate interactions with the system — loading and saving files, etc. — were also done using BASIC statements.

This was the design concept later used by many of the 8-bit generation of personal computers, as anyone who ever typed “LOAD ‘*’,8,1” to start a game on a Commodore 64 can attest. Following the norms of the time, even the original IBM PC dumped the user into a little used and seldom remembered BASIC environment if it didn’t find a DOS disk to boot at power-on. I’d been curious for years how we got from the command-line driven environments typical of most institutional computing to the interactive BASICs of these machines; now I think I have an idea.

Time-Shared BASIC represented a more welcoming environment for working and programming than was typical of the time, and this fact combined with the relatively low cost and easy maintainability of the HP-2100 line made these machines favorites of universities and even high schools. HP seems to have put considerable effort into designing and marketing the HP-2100 as a more user-friendly, accessible sort of machine. This manual is particularly interesting, being an introduction to BASIC programming pitched to the complete novice. It’s actually really well done, managing to walk the fine line of being friendly and accessible without falling into condescension. In light of all this, then, it’s not at all surprising that an HP-2100 would have found its way to Carleton College.

There were quite a lot of games and educational programs written in Time-Shared BASIC, and some of these have ended up on the Internet in the form of an unorganized dump to a huge tape image. So, I decided to try to bring up an emulated version of Time-Shared BASIC on my computer and to look through this mass to see if there might be an copy of the original The Oregon Trail in there somewhere. Well, it sounded like a good idea at the time, anyway…

You see, while there is an HP-2100 emulator available thanks to the amazing efforts of The Computer History Simulation Project, Time-Shared BASIC was a pretty complicated configuration. It was in fact TWO HP-2100s, one serving as a sort of gateway to users who connected via remote terminals and the other hosting the core of the OS itself. So, emulating the thing means running two separate HP-2100 emulators, loading the appropriate software onto each, and linking them together via sockets. Finally, one opens a THIRD window on one’s PC to telnet into system via the loopback address. I never would have gotten anywhere close to a working setup if hadn’t been for a Yahoo group dedicated to the platform, who host in their files section an emulator setup that almost worked right out of the box. I won’t bore you with the details of my struggles to get from almost to completely working; suffice to say that I finally got my own little Time-Shared BASIC system up and running.

And so I started going through the tape dump. This was almost 6MB of data, a large quantity indeed for a collection of BASIC programs often only a few kilobytes in length. Alas, though, no joy on The Oregon Trail.

But what I did find was pretty darn interesting, and more than justified the time it took to get to this point. Here were literally hundreds of BASIC programs: games, educational programs dealing with every subject, practical scientific and mathematical tools, etc. I even found what appears to be the original version of the old Star Trek game. There was obviously quite a thriving culture of program development and trading on this system from the late 1960s to the late 1970s. That’s perhaps not so remarkable in itself. What is, though, is that these programs were being written and used not by a priesthood of professionals as in the world of the IBM mainframe or a collection of focused hackers and researchers as in the world of the DEC PDP line, but rather by everyday students and educators. This gives their work a very different character. And if this sampling of their work is anything to go by, these people were very, very interested in games.

This mother lode deserves more attention, and I’m going to try to give it some and perhaps post a bit more about it in the future. (In particular, I want to see if I can find a version of the Hamurabi game Jason Dyer mentioned in a comment to the first post in this series.) But before I do that I’ll get back to The Oregon Trail proper next time around.

On the Trail of the Oregon Trail, Part 3
April 3, 2011

My search for the original Oregon Trail code as first written at Carleton College having turned up nothing, I set out to find the earliest version I could. That turned out to be the one posted by one Deserthat in his blog. This version appeared in the July-August 1978 issue of Creative Computing. But before I get to that let me talk just a bit about the seven years that elapsed between the game’s creation and its appearance in Creative Computing.

Rawitsch, Heinemann, and Dillenberger were roommates enrolled in the student teaching program at Carleton College in 1971; Heinemann and Dillenberger taught math, Rawitsch taught history. It was Rawitsch who first conceived of and designed The Oregon Trail as a board game, and Heinemann and Dillenberger who suggested that it be computerized and then programmed it in Time-Shared BASIC. The first outside of this trio to play it were the students in Rawitsch’s history class, on a teletype machine which Rawitsch wheeled into his classroom on December 3, 1971. According to Rawitsch, they “loved it.” Rawitsch and many other teachers in the Minneapolis school district used it frequently for the remainder of the term. When Rawitsch left the district in 1972, however, he deleted The Oregon Trail from the system and took it with him as a long role of printed paper which he ended up tossing into a drawer somewhere and forgetting about.

As it happens, Minnesota was something of a center of computer innovation in these days. In 1973 the state’s legislature founded an organization called The Minnesota Educational Computing Consortium (MECC), with a mandate to seek out and implement new applications for computers in education. A UNIVAC 1100 mainframe was installed at MECC’s Minneapolis headquarters, and some 1500 terminals were connected to it from schools throughout the state. In 1974, MECC hired Rawitsch to work as “a liason between MECC and a group of community colleges.”

Encouraged to think about new applications for computers in education, Rawitsch recalled that yellowing printout of The Oregon Trail. He punched it into a teletype connected to MECC’s UNIVAC over a “long Thanksgiving weekend” in 1974. The UNIVAC was a mainframe rather than a minicomputer like the HP-2100 — a very different proposition altogether. Luckily, it did have a version of BASIC available. [Actually, this is not quite correct. I learned after writing this that Rawitsch initially keyed the program into another HP-2100 system. See Part 4 of this series for more about that.] In addition to presumably being modified by Rawitsch or someone else at MECC to suit the UNIVAC’s implementation of BASIC, The Oregon Trail was also enhanced by Rawitsch himself to be more historically accurate, consistent, and entertaining. That version was played by thousands of schoolchildren all over the state during the next several years.

In 1977, MECC replaced its aging UNIVAC with a top-of-the-line CDC Cyber-73 system, and The Oregon Trail was modified once again to run on that system. This was the version that appeared in Creative Computing in 1978, and the version I back-ported to HP Time-Shared BASIC in order to experience The Oregon Trail in something close to its original form.

Now, as for Creative Computing… well, there’s one hell of an interesting story there as well.

Founded in 1974 by David Ahl, Creative Computing was the first mass-market magazine devoted to computers, predating even Byte by a full year. In keeping with its name, Creative Computing approached its subject not as an exercise in business and engineering, but as an artistic and cultural phenomenon. Its pages have plenty of technical advice and program listings, but also plenty of speculation on what the impending computer revolution really means. These “soft” articles are perhaps not surprising when one considers that many of the people who read the magazine could only dream of and speculate about access to a real computer of their own. There is much enthusiasm, but also some trepidation, most prominently in repeatedly expressed concerns about civil liberties in the new world to come. Both its idealism and its anti-authoritarian bent seem anchored in the by then fading counterculture of the late 1960s. I’m always reminded when I read it of the atmosphere around Berkeley’s Community Memory project, as described so well by Stephen Levy in Hackers.

Before founding Creative Computing Ahl was Education Marketing Manager for DEC. In keeping with this background and with its humanistic focus, Creative Computing was always very interested in the use of computers for education, devoting many pages to the subject in almost every issue. It’s thus not a big surprise that The Oregon Trail ended up there; if anything, the surprise is that it didn’t appear sooner.

By the time it did, MECC, which shows every sign of having been quite the visionary organization, was already getting involved with the new generation of “microcomputers,” as they were called in those days. MECC began installing Apple IIs into many Minnesota classrooms that year. And, yes, The Oregon Trail was ported yet again to run on them.

And so, with that history dispensed with, I’ll finally have a close look at the game itself next time around, which is after all where I’ve been trying to go with this shaggy-dog story all along.

On the Trail of the Oregon Trail, Part 4
April 21, 2011

It’s been a while since I’ve written on this subject. That hasn’t been because I’ve lost interest; rather the contrary actually. I’ve been doing some digital archeology with my new friends Michael Gemeny and Bob Brown of the HP 2000 Yahoo Group, and we’ve been able to turn up something very cool indeed.

On an old tape image from school district of York County, Pennsylvania, Michael found a program with the very promising name of “Oregon.” Sure enough, when we loaded it onto the system we found a version of The Oregon Trail dated March 27, 1975, more than three years older than the earliest previously known version. I’ve uploaded the program listing to this site, if you’d like to have a look. Looking at said listing has already proven to be very interesting for us.

First of all, it appears that the little history lesson I gave in part 3 of this series was not entirely correct. When Rawitsch came to MECC in 1974, he evidently did not port the game — or at least not immediately — to run on MECC’s centralized UNIVAC mainframe. He rather typed it out once again on another HP-2100 system. That makes a great deal of sense when one considers that these little systems were quite common in Minnesota schools and, indeed, in schools all over the country. By early 1975 MECC was obviously already giving the program away to school districts in other states.

It’s also evident that Rawitsch, or MECC, or at any rate someone, continued to improve and refine the game for years before it made its way to the Apple II. The 1978 version found in Creative Computing has some features not present in the 1975 version. In both versions, the player must enter a word quickly into the terminal and certain points: when hunting, when attacked by bandits, etc. The 1978 version, however, has a difficulty setting; when the program starts, the player is asked how good a shot she is, from “ace marksman” through to “shaky knees.” This determines how much time the player is given to type the word. And unlike in the 1975 version, in 1978 that word is chosen randomly from four possibilities — “BANG,” “BLAM,” “POW,” and “WHAM” to be specific. In 1975 it’s just good old “BANG” all the time. For those interested in looking at the differences, you can also download the 1978 version. This one isn’t quite as authentic as the 1975 one. I spent quite a lot of time fixing problems in the code that resulted from the OCR, and in the process also ported it back to HP-BASIC from CDC Cyber BASIC. I believe the problems have all been sorted out, however, and it should look and play just as it would have on an HP system back in 1978.

So, if we take the liberty of call these major version numbers 2 and 3, it sure would be nice to have version 1, wouldn’t it? Unfortunately, that doesn’t look likely to happen. Since this version apparently never made it beyond the system on which Rawitsch, Heinemann, and Dillenberger wrote it, and since Rawitsch deleted it off of that system in 1972, the only hope seemed to lie with that famous yellowing printout Rawitsch carried over to MECC. This picture from an Oregon Trail anniversary event at the Mall of America gave us hope, as Rawitsch is holding something that looks suspiciously like exactly what we were seeking.

I was able to contact Rawitsch about that, but the news was disappointing: he no longer has the printout. Barring a miraculous find, it appears that the 1975 version is the best we’re likely to do. Still, that’s a heck of a lot better than 1978. I feel lucky indeed to have found it.

Looking at the code of the 1975 version does tell some very interesting stories in itself. Michael knows much more about HP BASIC than I do, so I’m going to quote him here:

“The line numbers of this code tell an important part of the story which matches the historical accounts. From the looks of it, I would have said that it was being maintained by an accomplished programmer with a sense of pride and dedication. Then it seems to have been maintained by a less experienced programmer, or a programmer lacking the sense of pride, or the time, or perhaps the skill to maintain the appearance of the code.”

This latter programmer would of course be Rawitsch, who re-keyed and modified the program at MECC, initially at least on his own, and who, unlike Heinemann and Dillenberger, was not a trained programmer.

While most of the program is numbered in steps of 5, this pattern is occasionally broken. This is somewhat odd, as Michael informs me that HP-BASIC has a very powerful renumbering facility that Rawitsch perhaps didn’t know to take advantage of. Michael has assembled a list of lines which break the numbering pattern, and which therefore probably indicate places where Rawitsch made changes or additions at MECC. At the risk of belaboring the point, I’ll just paste that in here for the passionately interested.

Line 8- 11 Added MECC name, maintainer, and version
Line 262-263 Caution user against using a dollar sign
Line xx99 added section names in remarks
Line 1332 require user answer to be an integer
Line 1537 added caution about spending
Line 1752 discovered that ‘7 was a bell, added note to that
effect
Line 1902 made question two lines
Line 2392 fixed bug when riders don’t attack
Line 2672 added ammunition losses to heavy rains losses
Line 2792 added ammunition losses to fire losses
Line 2891 may have changed Indians to wolves and cause death
Line 3147 added ammunition losses to wagon damage
Line 3317 added ammunition losses to blizzard damage
Line 3650-3658 added next of kin and aunt Nellie
Line 4012 added another note about ‘7 bells
Line 4279 changed congratulatory message

Working from these clues and the historical record, it might be possible to reconstruct an “original” Oregon Trail. I’ve thought about it quite a lot, but I’m not really certain if it’s a good idea. The end result would inevitably be the product of a lot of conjecture. And, while we can learn much from the line numbers, we can’t know what modifications Rawitsch might have made within certain lines.

But perhaps you’d like to play this thing? If so, here’s how you can experience it in all its 1975 glory in HP Time-Shared BASIC.

1. Telnet to mickey.publicvm.com. (Telnet, mind you. None of that newfangled SSH!)
2. Slowly alternate CTL-J and CTL-M until you see a “PLEASE LOG IN” message.
3. Enter “HEL-T001,HP2000,1”. Without the quotes, of course — and note that those are zeroes. Oh, and the system isn’t case-sensitive, but for the authentic experience you might want to have your caps lock on.
4. Enter “GET-OREGON” to load the 1975 version, “GET-ORE2” to load the 1978 version.
5. “LIST” the program if you like, or just “RUN” it.

Bob Brown has graciously made this system available for all of us interested in this corner of computer history. Poke around as you like — there’s a lot of other interesting programs on there in addition to The Oregon Trail. But do please be polite and respectful if you decide to rummage.

As for our subject today… damned if the thing isn’t kind of fun. More on that when I wrap all of this up very soon now.

On the Trail of the Oregon Trail, Part 5
April 22, 2011

The Oregon Trail is all about resource management. You start the game with $700, which will have to serve as your non-renewable bankroll for the entire trip. From this you must buy your oxen team as well as food, ammunition, clothing, and “miscellaneous supplies” (which basically comes down to medical supplies). Play then proceeds through a series of up to 18 turns, each representing two weeks on the trail. At the beginning of each you can choose whether to hunt or simply press onward. In addition, you pass by a fort every other turn, where you can purchase additional supplies if you like. And you have to decide if you want to eat poorly, moderately, or well during that period, balancing your food supplies with the risk of illness that comes from a poor diet and hard work. During the body of each turn, you are usually subjected to a randomly chosen event of some kind. Most of these are of the unfavorable variety. This serious of misfortunes and disasters is what most people remember best about the game:

“WAGON BREAKS DOWN — LOSE TIME AND SUPPLIES FIXING IT.”
“OX INJURES LEG — SLOWS YOU DOWN REST OF TRIP.”
“BAD LUCK — YOUR DAUGHTER BROKE HER ARM. YOU HAD TO STOP AND USE SUPPLIES TO MAKE A SLING.”
“WILD ANIMALS ATTACK!”

According to the City Pages article, these last were hostile Indians in the original version, which would certainly have been more exciting to imagine if less politically correct. Telltale signs of code modifications around line 2885 bear this out. (Interestingly, the immortal “YOUR WAGON BROKE AN AXLE!,” source of a long-running Internet meme, is not yet in this version.) This tragic litany is occasionally broken by “HELPFUL INDIANS SHOW YOU WHERE TO FIND MORE FOOD,” but most of the time it’s a hard life indeed on the trail — which I suppose is accurate enough.

Rawitsch strove mightily to make the program accurate in its simulation of the trip, even constrained as he was by the limitations of his computing hardware and HP BASIC. The likelihood of the various randomized events are based as much as possible upon historical reality. The terrain changes; the going gets slower and harder later in the trip, when you begin to pass through the Rocky Mountains. Even the weather changes, requiring more clothing. In fact, there is more going on below the surface than you might realize. A peculiarity that The Oregon Trail shares with many other BASIC games of this era is that it seems to expect — even to depend upon — the player having a look at the code in order to fully understand what’s going on in the game. For instance, I didn’t realize that stopping at a fort for supplies dramatically reduces the miles you can cover in a single turn until I read that in the code. Likewise, it is easy to miss the terrain changes and the effect they have on the game if you haven’t at least skimmed through the code.

As a narrative experience, The Oregon Trail is more compelling than it perhaps has any right to be. Its communications are terse indeed, but one really does get the sense of embarking upon a long and dangerous journey. As I limped ever close to my destination of Oregon City, with one of my oxen injured, low on food and supplies, with winter fast closing in, I felt real tension and concern for my little family. The “you are there” feeling is further enhanced by the occasional “action” sequences in which you are given a limited amount of time to type the word “BANG” in the hopes of success at hunting or at defending yourself from bandits or animals. The game is relentlessly unforgiving; failing to stockpile enough food for the coming turn, or enough medicine or bullets, leads to instant death. Unlike in more typical early adventures games, where instadeaths are rather comical in their unexpectedness and cruelty, these feel believable. It was a hardscrabble existence indeed on the trail, and I’m sure plenty of real would-be settlers died for exactly these reasons. There’s actually a consonance between gameplay and narrative that’s rather rare to find even in modern storygames.

My personal strategy is to buy little if any food, reserving my precious money for other things. I then hunt about every other turn, taking advantage of the fact that I know my way around a keyboard pretty well. I also try very hard not to carry too much stuff at any time, as I always seem to end up losing it for nothing in some disaster or other. Traveling light, however, means more stops at forts; my biggest problem is usually running out of time, being trapped on a mountain trail when winter arrives. If you develop a favorite strategy of your own, maybe one that works better than mine, feel free to tell about it in the comments.

The Oregon Trail story after 1978 has been much better documented than has its early years, so I won’t devote much space to that. By 1980 MECC had purchased 500 Apple IIs and installed them in classrooms all over Minnesota, where children used them to (among other things) play the freshly ported Apple II version of The Oregon Trail. There followed a version with accompanying full-color illustrations (1985), a CD-ROM extravaganza version (1996), and, eventually, that Facebook version (2011), just to hit some of the highlights. When you strip away all of the multimedia that encrusts them, it’s really quite surprising how closely these later versions hew to the model that Rawitsch designed back in 1971. It’s not the most sophisticated storygame in the world, but it really is better than it ought to be. I’m glad I took the time to get to know it better, and, again, happy to be able to offer the code to anyone else who’d like to dive in. I’d go so far as to place it alongside Eliza and Hunt the Wumpus as one of the three pre-Adventure computer games that anyone interested in the history of interactive narrative really ought to know.

In Defense of BASIC
May 2, 2011

If there’s a programming language that just don’t get no respect, it’s BASIC. One could make a pretty good little bathroom reader from all the snarky comments it’s attracted over the years. My favorite is this gem from Edsger W. Dijkstra: “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC. As potential programmers they are mutilated beyond hope of regeneration.” (I think Dijkstra’s slightly stilted phraseology works better if you imagine it being said with a heavy Dutch accent.) That’s a bit hyperbolic, to be sure, but certainly BASIC has a lot to answer for. When I was a kid trading software on my trusty Commodore 64, saying a program was written in BASIC was as good as saying that it sucked. And things haven’t changed that much today. Has any development environment, ever, produced as much awful software as Visual BASIC? I must admit that learning that a program was written in Visual BASIC is still sufficient reason to make me not even try it.

But despite all that, BASIC’s importance in the history of computing is immense. Before it, there existed two principal computing cultures. First there was the mainframe culture. Centered around IBM and a few other big companies that tried to compete with it, it was marked by what Steven Levy so memorably called the “priesthood” model of computing common to government and big business: a few highly trained, lab-coated elites serving as minions of The Machine, doing everything by (IBM’s) book, with creativity and fun strictly Off Limits. The other culture was the hacker culture that sprung up at MIT and similar technical universities and perhaps the occasional smaller company: a group of generally young savants who were fascinated by the world inside the machine and lived to hack, who scoffed at the conservatism and groupthink of IBM and particularly embraced the smaller machines of the more freewheeling Digital Equipment Corporation (DEC). Different as they were, neither of these cultures cared much about making computers accessible to the everyman. Neither culture had any time for or interest in anyone who did not think in bits and bytes and registers.

When John Kemeny and Thomas Kurtz designed and implemented the Beginner’s All-Purpose Symbolic Instruction Code at Dartmouth University in 1964, they were not trying to please hackers or computer scientists. They were, rather, trying to make it possible for “ordinary” individuals to productively use computers. Today the idea of a programming language for the masses is almost oxymoronic; they simply load up their computers with the latest from Microsoft, Apple, or whomever, and leave the programming to the professionals. Back in 1964, however, and for quite a long time afterward, applications software in the way we know it today did not really exist. Using a computer for any but the most rote of tasks virtually required programming it; certainly, at any rate, using a computer creatively did. In attempting to bring computing to the masses, Kemeny and Kurtz’s goals were not so much technical as sociological, political, even ideological. A third computing culture, one I already began to discuss when mentioning HP Time-Shared BASIC and Creative Computing magazine in the context of The Oregon Trail, began with BASIC at Dartmouth in 1964 and remained associated with the language for many years.

While the priests in their climate-controlled data centers and the hackers sequestered away in their cubbyholes at MIT were oblivious to the changes that were wrenching society in the late 1960s and early 1970s, the BASIC culture was full of counterculture excitement. They were all about bringing these machines out of the banks and the ivory towers and putting them at the disposal of the street. That makes their work as important as that of the hackers who were inventing C and Unix and laying the foundation of the Internet at about the same time. Sometimes, more perhaps than either would first want to admit, the two cultures even intersected, as they did in the case of the game I want to talk about my next historical post, Hunt the Wumpus, which originated in HP Time-Shared BASIC but was novel and appealing enough to be attractive to the traditional hacker mindset as well — appealing enough to influence the first works of true IF.

As for BASIC, let’s remember to give it its historical due. If you’re excited by computers as artistic tools with relevance to the world and the people around them, you should recognize its place in forging those connections. The sniffing condescension of elitists like Dijkstra seems pretty unattractive indeed in this light.

So, yeah, respect is due. Now just don’t ask me to actually use the thing.

Hunt the Wumpus, Part 1
May 13, 2011

At the height of the hippie era, two fellows named Bob Albrecht and Leroy Finkel founded the publishing company Dymax in San Francisco to write books about BASIC. Yet Albrecht in particular had ambitions that went beyond merely selling books about computers. In those days computers were — literally — still the stuff of science fiction: huge, sinister machines that were always going haywire and causing Captain Kirk all sorts of problems. For this to change and for Albrecht’s dreams of computers as tools of fun and creativity to be realized, people needed access.

Albrecht, apparently a very charismatic and persuasive man, managed to wheedle a physical PDP-8 out of DEC and a remote terminal connection and an allotment of shared computing time out of HP. He soon turned Dymax’s Menlo Park offices into a sort of computing open house, where anyone could drop in and just play with the machines. By 1972 the for-profit publisher Dymax had spun off a very different institution Albrecht named The People’s Computer Company. PCC was not really a company at all — or at least not a company terribly interested in actually making money. Its name was in fact inspired by Big Brother and the Holding Company, the late-60s band that boasted one Janis Joplin as its singer, and this fact shows where its heart really lay. San Francisco was still largely living the hippie dream in 1972, even if some of the luster had begun to fade post-Altamont, and Albrecht and PCC fit right in with the counterculture there. Their mission was bring computers to the people, which they accomplished not only through their open house but also through a newsletter whose first issue appeared in October of 1972. Its banner read: “Computers are mostly used against people instead of for people. Used to control people instead of to free them. Time to change all that. We need a… People’s Computer Company.”

The atmosphere at the Menlo Park office was described in this way by Steven Levy in Hackers:

The air was usually filled with the clatter of terminals, one hooked to the PDP-8, another connected to the telephone lines, through which it could access a computer at Hewlett-Packard, which had donated free time to PCC. More likely than not, someone would be playing one of the games that the growing group of PCC hackers had written. Sometimes housewives would bring their kids in, try the computers themselves, and get hooked, programming so much that husbands worried that the local matriarchs were abandoning children and kitchen for the joys of BASIC. Some businessmen tried to program the computer to predict stock prices, and spent infinite amounts of time on that chimera. When you had a computer center with the doors wide open, anything could happen. Albrecht was quoted in the Saturday Review as saying, “We want to start friendly neighborhood computer centers, where people can walk in like they do in a bowling alley or penny arcade and find out how to have fun with computers.”

This was the environment that the 27-year-old Gregory Yob wandered into one day, probably around the time that that landmark first issue of PCC’s magazine was being published. At the time a certain collection of grid-based guessing games written by Albrecht himself was popular there. Hurkle was probably the first of the kind:

RUN
HURKLE

WANT THE RULES?Y
A HURKLE IS HIDING IN A GRID, LIKE THE ONE BELOW.

                          NORTH

               9    . . . . . . . . . .
               8    . . . . . . . . . .
               7    . . . . . . . . . .
               6    . . . . . . . . . .
               5    . . . . . . . . . .
        WEST   4    . . . . . . . . . .   EAST
               3    . . . . . . . . . .
               2    . . . . . . . . . .
               1    . . . . . . . . . .
               0    . . . . . . . . . .

                    0 1 2 3 4 5 6 7 8 9

                          SOUTH

TRY TO GUESS WHERE THE HURKLE IS HIDING. YOU GUESS
BY TELLING ME THE GRIDPOINT WHERE YOU THINK THAT
THE HURKLE IS HIDING. HOMEBASE IS POINT  0,0  IN
THE SOUTHWEST CORNER. YOUR GUESS SHOULD BE A PAIR
OF WHOLE NUMBERS, SEPARATED BY A COMMA. THE FIRST
NUMBER TELLS HOW FAR TO THE RIGHT OF HOMEBASE AND
THE SECOND NUMBER TELLS HOW FAR ABOVE HOMEBASE YOU
THINK THE HURKLE IS HIDING. FOR EXAMPLE, IF YOU
THINK THE HURKLE IS 7 TO THE RIGHT AND 5 ABOVE
HOMEBASE, YOU ENTER  7,5  AS YOUR GUESS AND THEN
PRESS THE 'RETURN' KEY. AFTER EACH GUESS, I WILL
TELL YOU THE APPROXIMATE DIRECTION TO GO FOR YOUR
NEXT GUESS. GOOD LUCK!

THE HURKLE IS HIDING - TRY TO FIND HIM!

WHAT IS YOUR GUESS?5,5
GO NORTH

WHAT IS YOUR GUESS?5,2
GO NORTH

WHAT IS YOUR GUESS?5,1
GO NORTH

WHAT IS YOUR GUESS?5,0
GO NORTH

WHAT IS YOUR GUESS?5,8

YOU FOUND HIM IN 5    GUESSES!!!
LET'S PLAY AGAIN.

Later variants made things a little more complicated: in Snark, one must enter the radius of a circle around a central gridpoint to be informed whether the snark is inside or outside, while Mugwump (the most difficult) tells only how far in a direct line the mugwump is hiding from each guess, leaving the player to puzzle out the direction for herself. In a sense, these are not really games at all; there is no way to really lose, only to end up with a lesser or greater total of guesses. One might imagine people competing against one another in the social atmosphere of PCC, but since each game is randomly generated it’s impossible to really know what two scores mean in relation to each other.

Yob’s reaction to these games was, in his own words:

“Eech!!” Each of these games was based on a 10X10 grid in Cartesian co-ordinates and three of them was too much for me. I started to think along the lines of: “There has to be a hide and seek computer game without that (exp. deleted) grid!!” In fact, why not a topological computer game — imagine a set of points connected in some way and the player moves about the set via the interconnections.

A “topological computer game” in which “the player moves about the set via the interconnections.” Starting to sound like something you recognize?

Hunt the Wumpus, Part 2
May 16, 2011

To hear Gregory Yob tell it, Hunt the Wumpus was as much inspired by his hatred of the Cartesian grid employed by Hurkle and similar games as it was by anything else. Yob wanted to make a monster-seeking game based on the dodecahedron, his “favorite Platonic solid.” I must say my own interest in geometry is limited enough that it’s hard for me to share Yob’s passion; certainly I lack a “favorite Platonic solid” to compare with Yob’s. I’m more interested in the other innovations Yob deployed on the way to implementing his dodecahedron.

Hunt the Wumpus is the origin point of all those twisty little passages that would be filling so many computer screens and graph-paper pads just a few years after its creation. Its world consists of a grid of twenty rooms, each of which is connected to exactly three other rooms. Some of these rooms have contents, which are randomly placed before each play: bottomless pits that result in instant death, “super bats” that carry the player to another (random) room, and of course the wumpus himself. If the player walks in on him, he has a 75% chance of merely wandering off to another room, but a 25% chance of eating her up right there. The wumpus can be killed only remotely, by firing an arrow from elsewhere into the room that contains him. The game in fact understands just two verbs: “move” and “shoot.” Gameplay, at least if you’re a cautious (not to say callow) sort like me, consists of moving carefully around the storyworld constructing a map of its rooms, connections, and hazards, and finally moving into position to take the kill shot against the poor wumpus. On the terminal, it looks like this:

HUNT THE WUMPUS

YOU ARE IN ROOM  20
TUNNELS LEAD TO  13    16    19

SHOOT OR MOVE (S-M)?M
WHERE TO?13

I FEEL A DRAFT
YOU ARE IN ROOM  13
TUNNELS LEAD TO  12    14    20

SHOOT OR MOVE (S-M)?M
WHERE TO?20

YOU ARE IN ROOM  20
TUNNELS LEAD TO  13    16    19

SHOOT OR MOVE (S-M)?

Okay, so it’s not too much to look at. When you play it for the first time, you might end up asking if that’s really all there is. Still, if you give it a decent chance you’ll find a well-constructed little game that can still be engaging, at least for the first few plays as you sort out how it works and how to beat it. From a design perspective, it’s biggest flaw is perhaps that you can often begin with a configuration like this:

I FEEL A DRAFT
YOU ARE IN ROOM  4
TUNNELS LEAD TO  3     5     14

The draft tells you that you are adjacent to a pit; one of those three tunnels, in other words, leads to death. Because you have not yet had a chance to gather any additional information, you are left to rely on blind chance. You must just pick one and hope for the best — hardly a fair situation.

But I’m not so interested in “pure” game design as I am in the history of ludic narrative. From that perspective, Hunt the Wumpus is hugely important in two ways.

First, it represents a radical change in perspective from games like Hurkle. While the player viewed those games from on-high, Wumpus places her in its storyworld. You are there, creeping from room to room in the darkness. Wumpus offers the merest stub of a narrative, but that stub combined with the switch from a third-person to a first-person perspective gives it a very different feel from Hurkle and its companions. Those games feel like abstractions; Wumpus is a much more immersive experience. It wasn’t quite the first game to put its player inside a storyworld — The Oregon Trail, at least, proceeded Wumpus by about a year and was possessed of a much more full-bodied narrative in addition — but it’s nevertheless a significant departure from the norm of its time.

Second, and even more importantly, Wumpus is a prototype version of the system of geography that is still with IF today: a set of discrete, self-contained rooms linked together by connectors the player can use to pass from one to another. Compass directions are not yet here, but the rest of the scheme is. Wumpus is all about mapping. The early IF games that would follow were continuing its tradition in being full of those twisty little passages that so frustrate modern players who try to go back to them today. This brings up a point that I’ve only recently started to grasp: the earliest IF was about geography and mapping more so than story or even puzzles. (I want to talk about the original Adventure just a bit after I finish up with Wumpus. I’ll have more to say about this idea then.)

Like The Oregon Trail, all signs point to Hunt the Wumpus having been originally written in HP Time-Shared BASIC. I was able to locate it along with its monster-hunting predecessors on tapes preserved by Bob Brown and Michael Gemeny of the HP-2000 Yahoo! Group. Its BASIC code was first published in a mid-1973 issue of the People’s Computer Company magazine, and later appeared in the October, 1975, issue of Creative Computing. The program that appeared there is almost identical to that which we found on the tape, with the only notable difference being some REM and PRINT statements found in the printed version that attribute it to Yob and plug Wumpus 2 and Wumpus 3, two sequels Yob had written by that time.

Unlike The Oregon Trail, which remained quite firmly under the thumb of MECC and was apparently spread only to educational institutions, Wumpus quickly spawned heaps of ports and adaptations on almost every viable computing platform of its era (and of every era since). By the time it appeared in Creative Computing Yob could write that, “I have reports of Wumpus written in RPG, a listing of one in FORTRAN, a rumor of a system command of ‘to Wumpus on a large corporation’s R&D computer system and have even seen an illustrated version for the Hazeltine CRT terminal!!” It was interesting enough as a game to cross the cultural boundaries that normally kept the cheerful BASIC hippies of PCC and Creative Computing separated from the world of the hardcore institutional hacker. At least by the 1975 release of Unix Version 6 (and quite possibly earlier), Wumpus had been ported to Unix C; a comment in the source cheerfully declares it “stolen from PCC Vol. 2 No. 1.”

Thanks to Bob Brown, you can experience the original version of this relic in its original environment if you’d like, as well as its immediate predecessors Hurkle, Snark, and Mugwump. Here’s what you need to do. (Yes, this is largely the same drill used to access The Oregon Trail on the same system.)

1. Telnet to mickey.publicvm.com. (Telnet, mind you. None of that newfangled SSH!)
2. Slowly alternate CTL-J and CTL-M until you see a “PLEASE LOG IN” message.
3. Enter “HEL-T001,HP2000,1″. Without the quotes, of course — and note that those are zeroes. Oh, and the system isn’t case-sensitive, but for the authentic experience you might want to have your caps lock on.
4. Enter “GET-WUMPUS” for Hunt the Wumpus; “GET-HURKLE” for HURKLE; “GET-SNARK” for Snark; or “GET-MUGWMP” for Mugwump.
5. “LIST” the program if you like, or just “RUN” it.

Have fun!

Will Crowther’s Adventure, Part 1
May 18, 2011

What remains to be said about Adventure? It has long and rightfully been canonized as the urtext not just of textual interactive fiction but of a whole swathe of modern mainstream videogames. (For example, trace World of Warcraft‘s lineage back through Ultima Online and Richard Bartle’s original MUD and you arrive at Adventure.) It’s certainly received its share of scholarly attention over the years, from Mary Ann Buckles’s groundbreaking 1985 PhD thesis “Interactive Fiction: The Computer Storygame Adventure” to Dennis Jerz’s superb 2007 article for Digital Humanities Quarterly, “Somewhere Nearby is Colossal Cave.” Still, since this blog has kind of turned into a history of early digital narratives without my entirely realizing it, it’s worthwhile to talk about its background. And having recently played it in its original Crowther-authored form as unearthed by Jerz in the course of researching his aforementioned article, I join Jason Dyer in having a few things to say about the experience. Finally, I’d like to make it as painless as possible for you to experience it in that authentic form as well, if you’re interested.

The outline of Adventure‘s history is probably familiar to many reading this, but in a nutshell it goes like this:

Back in 1975 a programmer and spelunker named Will Crowther had just gotten divorced. Missing his children and feeling somewhat at loose ends generally, he started to write a game in his spare time with the vague idea that he could share it with his two daughters, who now lived with their mother and whom he missed desperately. The game, which he named Adventure, combined his three biggest interests at the time: programming, caving, and playing a new tabletop game called Dungeons and Dragons.

How so? Well, the player would explore a geography loosely based on the Bedquilt branch of Kentucky’s Mammoth Cave, a place Crowther had spent years laboriously exploring and mapping; she would encounter treasures and creatures drawn from D&D in the process; and to win she would have to solve intricate puzzles while always maintaining close attention to detail, just like a programmer. Crowther had just invented the world’s first text adventure, in the process prototyping much that remains with the form to this day.

Those are the broad strokes. But let’s back up for a moment. Just who was Will Crowther? Where Wizards Stay Up Late, Katie Hafner and Matthew Lyon’s history of the development of the ARPANET (predecessor to the modern Internet), paints a pretty good picture of Crowther. His eccentricities have become so associated with the hacker mentality that they almost read like items on a checklist today. To wit:

He was almost disturbingly non-verbal, and rarely displayed any affect at all. He refused to dress up for any reason, even visiting the Joint Chiefs of Staff at the Pentagon in sneakers. And “he was a notoriously finicky eater (anything beyond the culinary level of a plain bologna sandwich was a risk), making him an impossible dinner guest or dining companion.” For all that, though, Crowther was a very unusual computer nerd in at least some ways. For one, he loved outdoor adventures, particularly rock climbing and of course caving. As befits an adventurer, he kept himself in excellent shape, in part by hanging by his fingers for hours on the frame of his office door. And most shockingly of all, he “never touched” soda.

Of course, what allowed Crowther to get away with eccentric behavior was the brilliance of his mind. Crowther’s Wikipedia page says as of this writing that, “He is best known as the co-creator of Colossal Cave Adventure.” That’s true enough, but it’s a bit unfair in a way to Crowther that Adventure and caving so dominate the page, for Crowther’s importance in computer history would be assured even had he never created Adventure.

Crowther was an absolutely key player on the tiny team that, beginning in the late-1960s, laid the foundation of the modern Internet. He wrote the software that ran on the Interface Message Processors (IMPs), the set of computers that shunted data around the nascent ARPANET; in other words, he wrote the firmware for the world’s first routers. He was one of hell of a programmer, “regarded by his colleagues as being within the top fraction of 1 percent of programmers in the world,” with a particular genius for writing incredibly compact and efficient code, a valuable skill indeed in those days of absurdly limited memory and processing power. If he had a fault, it was that he was more interested in prototyping, in showing that things could work and how, than in doing the hard, often tedious work of polishing and refining that results in a truly finished, production-ready program.

When we add all of this together, we can begin to see how Crowther could have birthed IF in such a complete form almost on a whim… and then abandoned it on another whim when (presumably) a more interesting problem came along.

Will Crowther’s Adventure, Part 2
May 24, 2011

Crowther’s original Adventure consists of relatively complete implementations of the above-ground section and the first underground level of the complete game that so many would come to know later. It peters out around the “Complex Junction” room, where a sign stands announcing, “CAVE UNDER CONSTRUCTION BEYOND THIS POINT. PROCEED AT OWN RISK.” It’s not kidding; things start to go haywire with some of the room connections at this point, such that navigating in some directions inexplicably returns you to above-ground locations. Beyond the ever-present challenges of navigation, there’s not really that much of a game here. Still, Crowther has laid down the basics of the thousands of text adventures that would follow, and even manages to include a few simple puzzles — and, yes, a maze.

In fact, one could say that the whole of Adventure is really one big maze. By far its biggest challenge is coming to understand and get around in the interconnected nodes (i.e., “rooms”) that make up its world. Even its few simple puzzles revolve around movement: we must deal with the snake to be allowed to progress beyond The Hall of the Mountain King; must find an alternative exit from the cave that will allow us to take the gold with us; etc. This may seem odd, unappealing, perhaps annoying to us when we play the game today — at least, that is, to those of us steeped in the culture of modern IF, with its emphasis on crafting an enjoyable narrative experience for the player. But was Crowther trying to craft a narrative experience at all? I don’t think so, actually.

Crowther is an extremely private person who is not much prone to revisiting the past or discussing his work, so there isn’t much direct evidence as to what he was thinking when he crafted Adventure. We might, however, find some clues in his game’s HELP text:

“I KNOW OF PLACES, ACTIONS, AND THINGS. MOST OF MY VOCABULARY DESCRIBES PLACES AND IS USED TO MOVE YOU THERE. TO MOVE TRY WORDS LIKE FOREST, BUILDING, DOWNSTREAM, ENTER, EAST, WEST, NORTH, SOUTH, UP, OR DOWN. I KNOW ABOUT A FEW SPECIAL OBJECTS, LIKE A BLACK ROD HIDDEN IN THE CAVE. THESE OBJECTS CAN BE MANIPULATED USING ONE OF THE ACTION WORDS THAT I KNOW.”

It’s interesting that Crowther foregrounds the geographical so obviously, and only then goes on to mention the possibility of manipulating just “a few special objects.” As a dedicated hacker, Crowther would almost certainly have come across Hunt the Wumpus. I think there’s a pretty good case to be made that Adventure started as another iteration on Yob’s idea of a “topological computer game,” and quite likely continued largely in that vein in its author’s mind right up until he abandoned its development. It’s very possible, even likely, that compass directions were a fairly late edition, that Crowther initially intended to have the player navigate entirely by working out keywords for getting from place to place, thus making navigation even more of the central chore. (While Dennis Jerz spoke to some who claimed to remember compass directions from the beginning, it’s possible they were misremembering; from reading the source it certainly seems that compass directions were a late — possibly almost a last — addition, perhaps upon realizing just how unworkable keyword navigation was likely to get over the course of a sprawling underground complex populated by dozens of similar rooms.) As a caver, meanwhile, geography would have been constantly on Crowther’s mind, not only as a point of factual interest but literally as a matter of life or death while underground; the in-home teletype connection through which Crowther likely developed Adventure was the same one that he used to enter survey data and construct maps of the real Mammoth Cave for the benefit of other cavers.

How much does it really matter how Crowther conceptualized his game? Perhaps not a lot. Still, it’s worth keeping in mind that expectations of both players and authors were very different back in the day, and that this can explain some things that authors did and players apparently enjoyed which we might find infuriating today. It’s certainly a point I’m likely to revisit again when I look at other historical works. Some scholars have recently advanced the idea that computer games are most of all about the experience of space, even going so far as to call them a form of architecture. It’s an interesting idea, and one that gains a lot of credence when I consider it in the light of these early works of IF. I’m not yet sure how to reconcile that idea with some of my other notions, but it’s more on my radar than ever in light of my experience with Adventure.

Abstractions like that aside, though, there is a certain stately appeal to this early iteration of Adventure which I find hard to explain. Crowther was by neither talent nor inclination a writer, but his terse, matter-of-fact descriptions bear the stamp of someone who knows the environment of which he writes. That gives his game, almost in spite of itself, a certain verisimilitude that would be lacking in many of the more polished efforts that would follow in later years. I want to look at how Woods expanded on this solid kernel next.

The Completed Adventure, Part 1
June 2, 2011

Don Woods was a graduate student in computer science at Stanford University when he first heard about Adventure in early 1977 from another student who had found it on, of all places, the Stanford Medical Center’s computer system. How it got from Crowther’s employer at the time he wrote it, BBN Technologies in Boston, to northern California is likely to remain a mystery. We do know, however, that Woods was intrigued enough by the game to secure a copy and install it on the PDP-10 minicomputer at the Stanford Artificial Intelligence Laboratory (SAIL), the place where he spent most of his time hacking. After plumbing its (limited) depths as a player, Woods conceived the idea of picking up where Crowther had left off and finishing the thing. Unfortunately, he had only the binary executable, not the FORTRAN source code. What followed is one of the legendary anecdotes of hacker lore, but it’s amusing enough that I’ll repeat it here.

Crowther’s program — as you can verify for yourself if you like — contains only one clue about its origin. In the in-game instructions it says, in Crowther’s inimitable terse diction, “ERRORS, SUGGESTIONS, COMPLAINTS TO CROWTHER.” Crowther had apparently never anticipated the program, at least in this incomplete state, getting beyond the small circle of BBN hackers who would immediately know who “CROWTHER” was and how to contact him. To make things even more difficult, Crowther had left BBN by the time Woods discovered Adventure, and was now employed by Xerox in California. (Perhaps Adventure actually came west with him?) Woods’s solution was to attempt to send an email to crowther@xxx, where “xxx” represented every single current domain on the Internet. In addition to laying claim to being the first spammer, Woods found Crowther at Xerox and secured his permission to complete the game and, most importantly, the precious source code. The Internet was a smaller place in those days…

Woods was not yet 23 when he discovered Adventure, but he had already secured a place for himself in hacker history by co-creating the joke programming language INTERCAL, one of the more bizarre and elaborate examples of hacker humor. In Hackers, Steven Levy makes much of the alleged contrast between East Coast and West Coast hacker culture:

“The difference began with the setting, a semecircular concrete-glass-and-redwood former conference center in the hills overlooking the Stanford campus. Inside the building, hackers would work at any of sixty-four terminals scattered around the various offices. None of the claustrophobia of Tech Square. No elevators, no deafening air conditioning hiss. The laid-back style meant that much of MIT’s sometimes constructive acrimony — the shouting sessions at the TMRC classroom, the religious wars between grad students and hackers — did not carry over. Instead of the battle-strewn imagery of shoot-’em-up space science fiction that pervaded Tech Square, the Stanford imagery was the gentle lore of elves, hobbits, and wizards described in J.R.R. Tolkien’s Middle Earth trilogy. Rooms in the AI lab were named after Middle Earth locations, and the SAIL printer was rigged so it could handle three different Elven type fonts.”

My own feeling is that Levy probably overemphasizes the cultural divide between the alleged crew-cut-wearing, conservative Heinlein fans clustered around MIT and the gentle Tolkien dudes of Stanford. Certainly the groups shared common preferences in hardware (DEC PDP systems), operating systems (TOPS-10), programming languages (no BASIC please!), and the general way that computing “should” be done that gave them much more in common with each other than either group had with the populists of the People’s Computer Company. I do think, however, that we can see some differences in the approaches that Crowther and Woods took to programming, differences which are not so much down to geography as temporality. Before I explain that, though, let me back up quickly and introduce some technical background.

Adventure ran on a DEC PDP-10 under the TOPS-10 operating system. As I’ve already mentioned in passing, DEC’s machines were the unqualified favorites of hackers for at least 20 years, from 1960 to 1980. Both the machines and the company that produced them were consistently innovative, large enough to get the job done but small enough to be flexible. Most importantly, DEC not only understood hacker ideals but embraced them, using cutting-edge research facilities like MIT and Stanford as laboratories to refine and even develop both software and hardware, and sometimes hiring the best and the brightest from that world to come work for them directly. The contrast to a condescending and stodgy behemoth like IBM could hardly have been more stark. TOPS-10, meanwhile, was as beloved as the hardware, having been developed and refined by DEC consistently since the late 1960s with the active assistance of the hacker community. Until Unix and DEC’s own successor OS TOPS-20 took its place, something that was already slowly beginning to happen in 1977, TOPS-10 was simply the hacker OS.

Adventure was written in FORTRAN (Formula Translating System), which was already a very old programming language when Crowther and Woods used it. It was in fact the very first significant high-level programming language to appear, having been introduced by IBM on its mainframe systems in the late 1950s. The version Crowther and Woods used obeyed the so-called FORTRAN IV standard, which dated from 1965. For all the grief that hackers gave BASIC, FORTRAN IV wasn’t much better, requiring as it did line numbers and copious use of the dreaded GOTO statement to get anything done. It was if anything particularly unsuited for writing a text adventure, including as it did almost no text storage or manipulation abilities whatsoever. That’s the reason Crowther chose to put all of the game’s text into an external file; it was just easier to deal with that way. Ironically, FORTRAN 77, a major expansion of the language that included proper string variables and heaps of other improvements, appeared the same year that Woods completed Adventure — but too late to be of use for that project.

So, then, why FORTRAN? Well, beyond FORTRAN and assembly language, in which a program like Adventure would have been tedious indeed to implement, normal TOPS-10 programming languages at this time included only the scorned BASIC and the perhaps even more loathed COBOL, a rigidly inflexible language designed for non-interactive batch processing — i.e., dull billing jobs and other rote calculating tasks that hackers found utterly uninteresting. Displaying plenty of vitriol if not much diversity of wit, Edsger Dijkstra made almost the same statement about COBOL as he had about BASIC: “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.” So, FORTRAN it was.

Crowther and Wood may both have been working in the same language, but the differences in their coding styles are immense. Crowther’s original source is itself a “maze of twisty little passages,” a huge pile of spaghetti code that is commented only sporadically and tersely. Efficient it undoubtedly is, but readable and maintainable, at least for anyone other than Crowther, it isn’t. Woods’s final version of Adventure is, by contrast, a model of clarity: commented frequently and at length, and structured as cleanly and logically as the limited tool that is FORTRAN IV will allow. Given the limitations Woods was working under, it’s a joy to read. Indeed, its clarity might help explain why Adventure was so quickly and so frequently ported to other languages and platforms; Woods’s code makes doing so almost a mechanical exercise.

Of course, we are comparing a complete with an incomplete program, and that is not entirely fair to Crowther. Certainly it’s unlikely that Woods’s code was so clean and readable during development as it became when the time came to release. Still, I think there might be something else going on here as well. Partly we might see a difference in personalities; Crowther had a reputation as a brilliant but a solitary programmer, after all, and doesn’t strike me as the kind of fellow interested in explaining himself or coddling those who followed in his footsteps. In addition, though, Crowther and Woods came from different hacker generations. Crowther came up in the 1960s, when the rules of “proper” coding were still largely unwritten and the emphasis was on just getting things done in whatever way the primitive hardware of the day could be coaxed into doing it. Woods came up in the 1970s, when the importance of structure, readability, and maintainability were becoming clear, and computer scientists were laying down the rules of good programming practice which we still follow — with a few additions, of course — today.

Next up, some observations on actually playing the completed Adventure.

The Completed Adventure, Part 2
June 3, 2011

(Warning: spoilers galore in this one, folks.)

Woods replaced virtually none of Crowther’s original text in Adventure, but simply built upon it, by fleshing out Crowther’s minimalist help text and of course adding many more locations to explore. The contrast in the two men’s coding styles has no parallel in their prose, as Woods ably continues in Crowther’s terse but just-evocative-enough style. The player notices no obvious point where Crowther left off and Woods picked up, and, indeed, would probably never guess that the latter parts were written by a different person entirely.

If we insist on finding differences, we might point to Woods’s willingness to indulge in more fantastic and anachronistic elements, as well a willingness to allow himself a bit more poetic license here and there. As an example in the former category, the vending machine selling batteries feels like something Crowther would never have added. (Of course, it’s also true that Crowther’s lamp never ran out of batteries in the first place, because it was almost certainly conceived by him as a carbide lamp of the sort he took with him on his caving expeditions rather than a battery-powered job; in this case the very different backgrounds of the two men does affect the finished work.) (Edit: Actually, it seems the lamp was electric in Crowther’s original. See the response to rub: “RUBBING THE ELECTRIC LAMP IS NOT PARTICULARLY REWARDING.” Lucky I qualified my “certainly” with an “almost…”) In the latter category, we have the most elaborate and extended room description in the entire game, for the “Breath-Taking View” located deep, deep within the cave complex:

YOU ARE ON THE EDGE OF A BREATH-TAKING VIEW.  FAR BELOW YOU IS AN
ACTIVE VOLCANO, FROM WHICH GREAT GOUTS OF MOLTEN LAVA COME SURGING
OUT, CASCADING BACK DOWN INTO THE DEPTHS.  THE GLOWING ROCK FILLS THE
FARTHEST REACHES OF THE CAVERN WITH A BLOOD-RED GLARE, GIVING EVERY-
THING AN EERIE, MACABRE APPEARANCE.  THE AIR IS FILLED WITH FLICKERING
SPARKS OF ASH AND A HEAVY SMELL OF BRIMSTONE.  THE WALLS ARE HOT TO
THE TOUCH, AND THE THUNDERING OF THE VOLCANO DROWNS OUT ALL OTHER
SOUNDS.  EMBEDDED IN THE JAGGED ROOF FAR OVERHEAD ARE MYRIAD TWISTED
FORMATIONS COMPOSED OF PURE WHITE ALABASTER, WHICH SCATTER THE MURKY
LIGHT INTO SINISTER APPARITIONS UPON THE WALLS.  TO ONE SIDE IS A DEEP
GORGE, FILLED WITH A BIZARRE CHAOS OF TORTURED ROCK WHICH SEEMS TO
HAVE BEEN CRAFTED BY THE DEVIL HIMSELF.  AN IMMENSE RIVER OF FIRE
CRASHES OUT FROM THE DEPTHS OF THE VOLCANO, BURNS ITS WAY THROUGH THE
GORGE, AND PLUMMETS INTO A BOTTOMLESS PIT FAR OFF TO YOUR LEFT.  TO
THE RIGHT, AN IMMENSE GEYSER OF BLISTERING STEAM ERUPTS CONTINUOUSLY
FROM A BARREN ISLAND IN THE CENTER OF A SULFUROUS LAKE, WHICH BUBBLES
OMINOUSLY.  THE FAR RIGHT WALL IS AFLAME WITH AN INCANDESCENCE OF ITS
OWN, WHICH LENDS AN ADDITIONAL INFERNAL SPLENDOR TO THE ALREADY
HELLISH SCENE.  A DARK, FOREBODING PASSAGE EXITS TO THE SOUTH.

It’s somehow hard to imagine Crowther writing that; it’s a long way indeed from the humble wellhouse by the roadside in Kentucky at which the player began. It’s often been compared with the descriptions of Mount Doom found in The Return of the King, but Woods, while admitting he had read Tolkien before working on Adventure, has denied using him as a conscious inspiration. Oddly, this room has no practical function whatsoever. Perhaps Woods conceived of it as a reward of sorts for the persistent player who made it this far underground.

And what sort of challenges must a player who made it so far have overcome? Well, I divide them into three categories.

First there are the logistical challenges — or, if you prefer, the emergent challenges. These involve the practical difficulties of getting about in the 140 intricately interconnected rooms that make up Adventure‘s storyworld and returning all 15 treasures found therein to the wellhouse: managing the lamp’s limited power reserves, dealing with the limited carrying capacity of the player’s avatar, and, most of all, mapping, mapping, mapping. A player who wants to get anywhere in the game has to plan her underground expeditions much like one of Crowther’s caving teams would have. I’ve already stated my belief that, at least in Crowther the caver’s mind, this was the real heart of the game, its real challenge. If that seems a stretch, imagine playing Adventure for the first time in 1976 or 1977, with no knowledge about how text-adventure geographies are supposed to work; imagine trying to figure out how to map that maze when the old dropping-items-in-each-room trick wasn’t second nature. Modern IF may have largely rejected many of the tropes found under this category, but they are a fundamental part of what Adventure really is, and, I would argue, even an important part of the appeal it held for so many back in the days of yore.

Then there are the good puzzles. These are simple, straightforward challenges, solvable with a bit of basic logic and common sense. So, you must find another exit from the cave since you can’t carry the gold nugget (must be one hell of a nugget!) up the stairs; you must employ the trident to pry open the giant clam shell; etc. In contrast to the sort of conundrums Infocom and others would be offering up in just a few years, these are gentle indeed.

But then we come to the bad puzzles. There aren’t too many of them, but they’re a scary lot. There’s the dragon puzzle: when the player types, “KILL DRAGON,” the game responds, “WITH WHAT? YOUR BARE HANDS?” Whereupon she must type, “YES,” to get the reply, “CONGRATULATIONS! YOU HAVE JUST VANQUISHED A DRAGON WITH YOUR BARE HANDS! (UNBELIEVABLE, ISN’T IT?)” In presaging some of the ridiculous puzzles in the inexplicably delightful The Hitchhiker’s Guide to the Galaxy of many years later, this is almost amusing enough to be forgivable. Not so the climactic puzzle, in which the player is expected to intuit a heretofore nonexistent property of the black rod she’s been toting around almost since the game began. She’s expected to “BLAST” the control room of what has now been revealed to be a sort of amusement park rather than a natural cave complex. She can only “BLAST,” mind you. No “BLAST WITH ROD,” no “WAVE ROD.” Unless I’m missing something, this action and this phrasing of it are utterly unmotivated. It’s perhaps the most egregious example of guess the verb and just about the worst puzzle in general I’ve ever seen, playing like a satire of the worst of old-school text-adventure tropes.

Upon encountering such delights, one is left shaking one’s head and trying to figure out how we got from category-two to category-three puzzles, with no gradation in between. It’s particularly surprising to encounter puzzles like these in light of the fact that in some ways Adventure is surprisingly friendly and progressive; consider, for example, the automated hint system that dispenses clues here and there when the player has floundered long enough in one of its trickier sections.

We might find an answer if we consider the capabilities of the Adventure program itself. Woods was working with an extremely simplistic world model joined to a two-word parser. Such a system imposes a real limit on how intricate a puzzle an author can devise. Even some of Adventure‘s better puzzles are made more frustrating than they should be by parser limitations. Consider the case of the bear that the player can tame and lead around to scare away the troll. It’s kosher enough as a puzzle — except that the player must divine the syntax “TAKE BEAR” (presumably not quite what she’s actually doing) to accomplish it. Perhaps Adventure‘s underlying technology can really only support two kinds of puzzles: the extremely simple and the blatantly unfair. Guess the verb, after all, is always easy to code.

And of course we have to consider cultural differences. There seems to have been a real sense on everyone’s part that Adventure should be hard, that getting to the end of it should be a huge accomplishment. Thus all the emphasis the game places on scoring points. Like with the coin-op arcade games of the day, players would compare scores for sessions that resulted in eventual “defeat,” and would be satisfied with at least getting further than the rest of the office had managed. Less competitive types, meanwhile, could form teams to work on the game together, a natural result of the social environment in which PDP-10s were inevitably placed.

Finally, the enterprising could always turn to the freely distributed source code. Considering that most of the first people to play the game were hardcore hackers, I suspect that this was the way that the absurd “BLAST” puzzle first got solved. (EDIT: Or perhaps with a machine-language debugger. Tim Anderson states in Infocom’s “History of Zork” that this was the method used to figure out how to get the “last lousy point.” It does appear from anecdotes like these that Adventure was first distributed only in binary format, and that the source came afterward.)

I’ve gone on about these things at length because I think they will be relevant not just for understanding Adventure but also for understanding many of the games that would come afterward, many of which would be so infuriating that plenty of people even today can’t mention text adventures without cursing. Next time I’ll finish up this little miniseries on Adventure by talking about the game’s rapturous reception and legacy — and I’ll provide a final tally of exactly who was responsible for what parts of the final design, so you can know to whom to send your bouquets and your brickbats.

The Completed Adventure, Part 3
June 4, 2011

The PDP-10 system on which Don Woods completed Adventure was an expensive resource shared by many; Stanford did not purchase it to enable virtual spelunking. Perhaps to head off the inevitable complaints of his superiors, Woods built into the program the concept of “Cave Hours.” If someone tried to play during times of peak demand — by default from 8:00 am to 6:00 pm, excluding weekends and holidays — she was allowed only to take a “short exploration,” limited (by default) to 30 minutes and without the option to save her progress. Some design choices also seem calculated to encourage players to play in shorter sessions over a period of weeks or months rather than binging for hours at a time. For instance, during non-peak periods a player can save her progress, but she is forced to immediately quit the game upon doing so, and cannot restore her session and resume playing for 90 minutes. (Of course, things like this also served, in keeping with the philosophy described in my last post, just to make the game hard.)

These restrictions could be altered by an administrator by entering “MAGIC MODE” at an in-game prompt. If she responds correctly to what follows she becomes a sort of root user, able to change the program’s settings:

MAGIC MODE

ARE YOU A WIZARD?

YES

PROVE IT!  SAY THE MAGIC WORD!

DWARF

THAT IS NOT WHAT I THOUGHT IT WAS.  DO YOU KNOW WHAT I THOUGHT IT WAS?

NO

NODDG

BMAFH

OH DEAR, YOU REALLY *ARE* A WIZARD!  SORRY TO HAVE BOTHERED YOU . . .
DO YOU WISH TO SEE THE HOURS?
YES

         Mon - Fri:  Open all day
         Sat - Sun:  Open all day
         Holidays:   Open all day
DO YOU WISH TO CHANGE THE HOURS?
NO
DO YOU WISH TO (RE)SCHEDULE THE NEXT HOLIDAY?
NO
Length of short game (null to leave at 30):

NEW MAGIC WORD (NULL TO LEAVE UNCHANGED):

NEW MAGIC NUMBER (NULL TO LEAVE UNCHANGED):

Latency for restart (null to leave at 90):

DO YOU WISH TO CHANGE THE MESSAGE OF THE DAY?
NO
OKAY.  YOU CAN SAVE THIS VERSION NOW.

BE SURE TO SAVE YOUR CORE-IMAGE...
CPU time 0.01   Elapsed time 33.98

EXIT

The administrator must work out the proper response using a complex cipher algorithm based not only on the randomly chosen sequence of characters the game sends to her but also on the exact current system time. This portion of the source code is obfuscated as much as possible for obvious reasons, although I’m sure the sufficiently determined could work it out. Presumably the algorithm must have been passed secretly among administrators, but this is one aspect of Adventure I’ve never heard too much about. If anyone knows anything more about how this was generally handled, by all means leave a comment to tell us about it.

One interesting aspect of the cave hours system is the way that it treats Adventure not as a narrative or even as a game, but rather as a location — specifically, as a sort of virtual amusement park. The visitor who attempts to enter during peak hours is told, “I’M TERRIBLY SORRY, BUT COLOSSAL CAVE IS CLOSED,” followed by details of its “open hours.” This idea is echoed in the endgame, as the player suddenly finds herself dropped into the control room of this underground park. It all serves to emphasize again that Adventure is ultimately all about location, location, location — and that Don Woods apparently had a bit of an amusement-park fetish.

Whatever its other implications, system administrators would soon have reason to bless Woods for including cave hours, even as they probably cursed him for ever unleashing Adventure upon them in the first place. Because, you see, Adventure turned out to be popular — really, really popular. Solving it became the obsession of hackers across the country and, eventually, all over the world; legend has it that IT departments and university computer-science departments pretty much stopped doing much of anything else until they had won. Even disallowing play during business hours is after all of limited utility when all of the people who are supposed to be accomplishing useful things during said business hours are passed out at their desks after playing Adventure all night. One apocryphal quote claims that Adventure set the entire computing industry back by two weeks.

And once that crisis was passed, lots of hackers in lots of places promptly started trying to make their own versions. Adventure-like games became Adventure games became adventure games, and a genre was born. For several years the most complex examples of the new form continued to appear on larger institutional systems in places like MIT University, the Stockholm Computer Center, and Cambridge University. Jason Dyer has been doing a great job of covering that aspect of early adventure gaming, digging into some largely forgotten works as well as the heavy hitters like Zork. At least for now, though — and, as always, as time permits — I want to look at how the innovations of Crowther and Woods, not to mention those of Gregory Yob and Don Rawitsch and so many others, began to come home, on the first practical home computers that were appearing at the same time that Adventure was paralyzing the world of the institutional computer.

Before I say goodbye to Adventure, here’s a final tally of who created what.

Crowther:
basic concept of the text adventure
compass directions
the dwarves
“Maze of Twisty Little Passages, all alike”
geography and some puzzles up to the “Complex Junction”

Woods:
inventory limit
“Maze of Twisty Little Passages, all different”
cave hours
geography and puzzles from the “Complex Junction”
scoring system
save system
the pirate
limited lamp battery life

You have a lot to answer for, Don Woods! But we love you anyway… at least you didn’t implement any hunger timers.

The Trash-80, Part 1
June 6, 2011

The conventional wisdom, as found in fictionalized accounts like Pirates of Silicon Valley and as regurgitated by lazy journalists everywhere, is that the personal computer was invented in a garage in Palo Alto by the charming rogue Steve Jobs and his sidekick Steve Wozniak, who was admittedly a bit weird and nerdy but acceptable in the role of second fiddle. Given his role and personality, it’s not really surprising that Jobs hasn’t done anything to divest the world of this founding myth. Somehow more disappointing, though, is the similar failure of Wozniak, who always struck me as the member of the pair I’d most like to have a beer with. Yet Woz, alas, went so far as to make part of the subtitle of his autobiography “How I Invented the Personal Computer,” when the hard facts are that the legendary Apple II was neither the first fully assembled PC available for purchase (that was the Commodore PET), nor the most successful of the formative era (that was the Tandy / Radio Shack TRS-80, the subject of my entry today). Granted, the Apple could make a pretty good claim for being the best of this dynamic trio of 1977, but that’s a whole other kettle of fish.

(Update: In the course of researching later posts I’ve come upon some new facts that rather muddy these waters. It is true that Commodore announced the first turnkey PC in the form of the PET at the Winter Consumer Electronics Show in January of 1977, and brought with them a rough prototype that, at least by the last day of the show, basically worked. However, Commodore did not finally start shipping finished PETs to customers until September of 1977, by which time the Apple II had been shipping for almost three months. So, Apple was the first to market with a turnkey PC, if not the first to begin development on one. (What was Commodore doing for so long? Well, if you have to ask you don’t know Commodore…) But I still think that Apple’s role in the first ten years of the PC era is, while very important, exaggerated by the “winners write the history” syndrome.)

The reasons for the conventional wisdom about the history of the PC aren’t hard to divine. It may be a cliché to say that history is written by the victors, but that makes it no less true — and with Commodore defunct for 17 years at this writing and Radio Shack, or “RadioShack” as they now prefer to be called, having given up on manufacturing computers almost as long ago, the winners in this case are obvious. Further, the story of Apple Computer, of these two plucky all-American visionaries inventing the future in their garage, is the sort that the mainstream media loves to write. How can Commodore, an ex-calculator and office furniture manufacturer led by an abrasive and petty middle-aged man, compete with the two Steves? How can the conservative, stodgy, very establishment Tandy Corporation, parent of the Radio Shack chain of electronics stores?

For those who are not American or who missed this corner of American retail culture, I’m going try to describe Radio Shack, as least as they were up to a decade or so ago. That’s about how long it’s been since I had much real contact with any of their stores; it’s possible that the new milennium and the bold switch from “Radio Shack” to “RadioShack” has changed everything. But somehow I doubt it; Radio Shack strikes me as one of those seemingly eternal institutions like Montgomery Ward that can only be itself, until one day, poof, it’s suddenly gone altogether. I actually must admit to some surprise that Radio Shack is still around in 2011. It feels like something from another time, a musty piece of shopworn Americana that inexplicably still lives and breathes — and much as I’m about to make fun of them, that makes me feel kind of warm and happy inside.

There were two distinct kinds of Radio Shack customers.

The first was your uncle Jerry, who worked down at the lime mine, drank a twelve-pack of Bud every weekend, and tooled around in a Ford Granada. Jerry shopped at Radio Shack for the same reason that he bought the Granada: some vague sense of patriotic obligation. And like with the Granada, the stereos and televisions he bought at Radio Shack basically got the job done, even if knobs tended to fall off, inexplicable discolored patches tended to appear, and unexplained buzzes occasionally issued forth then disappeared again. Operating them always felt a little bit more awkward than it ought to, and as for the aesthetics of the things… well, let’s just say aesthetics weren’t a priority at the Shack and leave it at that.

And then there was your brother-in-law Don, the real-estate agent and frustrated inventor. Don had subscriptions to Popular Electronics and Radio-Electronics among others, and read every issue cover to cover. His garage no longer had room for the family cars, filled as it was with HAM-radio equipment, every television discarded in the neighborhood for the last ten years (he was sure they’d come in handy for something at some point), and that homemade soda fountain that hadn’t yet produced a swallow of drinkable soda but had exploded alarmingly on several occasions. When Don came to Radio Shack, he strode right past the Uncle Jerrys and the displays of “Realistic”-brand consumer electronics to the back of the store, where hung transistors, diodes, capacitors, and God knows what else — an area that was incomprehensible to anyone else, including the poor befuddled employees hanging about the place. These were all allegedly paid on commission, but seemed strangely unaware of that fact, and mostly confined themselves to trying to push batteries on everyone who walked through the door for reasons that were known only to Radio Shack management.

Occasionally a specimen from outside the normal Radio Shack milieu would wander in; there were lots and lots of Radio Shack stores, literally thousands spread all over the country, so they were occasionally selected by default, even if only for the purpose of buying batteries, in places where the alternatives were, shall we say, limited. Given the sales staff’s passion for batteries, one would think these people would be greeted with open arms, but this was not the case. Radio Shack in fact had in place a policy almost guaranteed to drive them from the store in abject frustration, one that would soon have them driving right past the convenient local Shack to get their batteries somewhere, anywhere, else.

When you made it to the sales counter with your $3.00 package of batteries, the heretofore apathetic salesperson would spring to life, asking in an excited tone whether you were on the mailing list. “No thank you,” you might answer, “I’d just like to buy the batteries, please,” optimistically attempting to hand over your $5.00 bill. What you failed to understand was that the salesperson had no more interest in your money at this point than he did in the racks of capacitors at the back of the store; what he wanted was to get you and your address “into the system” by whatever means necessary. Only after accomplishing that, a laborious process likely entailing a false start or two and lots of fiddling with a balky terminal, was he interested in taking your money and earning his freebie commission on this pack of batteries you had walked in and picked up off the shelf for yourself. This process was not optional; you could provide a name and address along with your cash or you could take your goddamn business elsewhere.

Given the priority Radio Shack placed on acquiring this information, one would think that they would treat it as a precious resource. Oddly, though, this didn’t seem to be the case. Even well into the 1990s, long after every other retail chain had networked its computer systems together, Radio Shack, the “technology store,” seemed to have no shared customer database whatsoever. Therefore every time you dropped into a different location of the 237 in your city to get some more batteries, you would have to go through this process again. Even more bizarrely, even a single store had only about a 50-50 chance of retaining your information from one visit to the next. Truly, Radio Shack refined customer aggravation to an art. Only Jerry was willing to put up with it, because it was his duty to “buy American,” and Don, because you just couldn’t get this shit anywhere else.

When we take all of these factors into consideration it becomes clear why Radio Shack had an image problem in 1977. That’s not an unusual state of affairs for the company; having an image problem is a part of what Radio Shack is, as fundamental to it as those mazes were to Adventure. Radio Shack has always been, and will always remain, the anti-Apple Store, the antithesis of hipster cool. When they decided to release their own computer that year, the awkward but lovable contraption that resulted left no doubt about its parentage.

The Trash-80, Part 2
June 10, 2011

In the mid-1970s a fellow named Don French was working at Radio Shack’s corporate headquarters in Fort Worth, Texas. Unlike pretty much everyone else there, Don was himself an amateur electronics enthusiast, and so actually understood those strange displays at the back of the Radio Shack stores. And he was fascinated with the idea of computers, so much so that in mid-1974 he was one of the few who managed to put together a working version of Jonathan Titus’s Mark-8 computer after seeing it in an issue of Radio-Electronics magazine. Barely six months later, when the vastly more accessible MITS Altair 8800 arrived, hobbyists across the country began hacking together machines of their own, forming loose communities of interest such as the famous Homebrew Computer Club attended by Jobs and Wozniak among other current and future luminaries. The people involved with these new “microcomputers,” as they were then known, were mostly experienced solder-gun wielders who had cut their teeth on HAM radio or radio-controlled cars — the sort of do-it-yourselfers, in other words, who had been standing in the back of all those Radio Shacks digging through boxes and shelves of wires and diodes for years. Now that they worked with computers, they continued to use the Shack as their source for the non-specialized components they needed.

French understood the hunger so many people had for a computer of their own, because he had felt the same hunger himself. And he thought that Radio Shack could do very well if it began serving that hunger more directly, by offering computer equipment at its thousands of stores instead of leaving hobbyists to rely on the network of tiny, often dodgy companies that had jumped into the new market. His problem was convincing management, and that was a tough nut to crack indeed; few have ever accused Radio Shack’s management of vision, after all.

Still, even they eventually had to see that something was happening when an event like the March, 1976, World Altair Computer Convention could attract over 700 people from seven countries to Albuquerque, New Mexico, home of MITS. After that, management began to take French’s ideas a little bit more seriously, and about May of 1976 officially authorized him to start making a computer for them. But they certainly didn’t overdo their commitment; French got to hire exactly one engineer to work on the project. Fortunately, he made a good choice in Steve Leininger, a Homebrew Computer Club member whom he imported from Silicon Valley. Together they labored over the TRS-80 in a disused room inside Radio Shack’s speaker factory, with French taking the Jobs role of public relations-man, business manager, and general vision articulator, and Leininger taking the Wozniak role of technical designer.

A few months in something happened that changed the direction of the project dramatically. (This anecdote and many others is taken from Priming the Pump, a fun if rambling memoir of the TRS-80 scene by David and Theresa Walsh.)

The whole project almost died one day when a heavy package came in the mail to the engineers. It was an expensive digital clock kit that customer had put together and sent back. The customer’s story was that he had followed all the instructions and the clock didn’t work; in fact it blew a fuse when he plugged it in. “We opened it up,” says Leininger, “and the thing had an eighth of an inch of solder all over the bottom. The instructions said, ‘Put all the parts on the board, turn the board over, and solder everything to the bottom of the board.'”

That, my friends, is why it was best for everyone concerned if Uncle Jerry confined himself to the front of the store. With visions of thousands of do-it-yourself computer kits coming back to them in a similar state, management almost killed the project. Instead, miraculously, French was able to convince them to do something else: to make the machine a complete, turnkey computer rather than a kit. It’s good that he did, because in January of 1977 a struggling calculator manufacturer called Commodore Business Machines announced the PET, an event which marked the beginning of the end of the Altair era of (literally) home-brewed computers. With little funding and turnkey systems by Commodore and Apple in the pipeline, French and Leininger did what they could with what resources and time management allowed them to have. The result, which was officially announced on August 3, 1977, and started shipping about a month later, was a solidly engineered core brocaded with a heap of questionable choices, the sort of thing that could only have come from Radio Shack.

Unlike the PET and Apple II, which used the MOS 6502 CPU, the TRS-80 used the Zilog Z80. (The first part of the name “TRS-80” stood for Tandy Radio Shack, the second for the Z80.) It was clocked at 1.78 MHz, 78% faster than the Commodore or Apple, and it would prove quite amenable to expansion and modification. Luckily so, because the version that Radio Shack put on sale that autumn was… limited.

Inside its chunky plastic case was just 4 K of RAM, because that’s all Radio Shack would pay for. They also refused to pay the licensing fees to acquire BASIC from what was at that time the leading provider of microcomputer BASICs, a little company called Micro-Soft. Just as well, because they also weren’t going to pay for the 12 K of ROM needed to house it. So Leininger himself hacked together a limited subset of the language based on a standard known as Tiny BASIC, and squeezed it into the 4 K of ROM Radio Shack allowed him. This full-featured development environment came equipped with exactly three error messages: “HOW?” when some sort of logical error such as division by zero occurred; “SORRY” when out of memory (something that must have happened quite a bit); and “WHAT?” when it just didn’t understand you at all (something else that must have happened quite a bit).

At some point, Radio Shack had decided they wanted to sell the TRS-80 as a truly complete computing package, with a monitor and a permanent storage solution included. So, they grabbed the cheapest and smallest black-and-white television in their catalog (the TRS-80 had no color capabilities) and also the cheapest audio-cassette recorder and the turnkey package was complete. The computer itself was molded in what Radio Shack optimistically called “Mercedes silver” because that was the color of the already extant TV-cum-monitor. They didn’t even bother to remove the volume control from the tape recorder, which led to all sorts of fun. Here’s some contemporary advice on getting it calibrated to actually, you know, function, from an early issue of SoftSide magazine:

Get an AM radio and place it beside your computer keyboard (on the side opposite the tape recorder, so that it doesn’t get in the way). Tune it to a spot in between stations and turn the volume down low enough so that it isn’t too annoying. This will help you keep track of what is going on inside the computer when you are loading from tape. If there is little or no sound, you are either listening to a blank tape, or the volume is too low for the computer to pick up the information. If you get an interrupted buzzing, the volume is either too loud or too soft. Turn the volume (on the tape recorder, not the radio) so that there is a steady tone. Then rewind the tape and start over. If you get a steady tone, the volume is approximately (unfortunately, only approximately) correct.

Such tricks were only possible because of the truly epic levels of RF interference that the TRS-80 put out. Televisions were best placed at the other side of the house from it, and (hopefully false) rumors had it that a handful of well-placed machines could take out whole city blocks. In fact, the original TRS-80 design was finally discontinued in 1981 because it violated FCC standards for RF interference. (How it ever got approved in the first place is the real mystery…) TRS-80 loyalists darkly suggest to this day that the machine was ratted out to the FCC by Texas Instruments, who were about to enter the market with a machine of their own and wanted to trim the field a bit.

All in all, the TRS-80 reminds a bit of the old MG and Fiat sports cars my friends and I used to tinker with years ago. As we stalwartly intoned every time trying to run the engine, the windshield wipers, the headlights, and the radio off a single Lucas electrical system left us with a smoking hunk of melted plastic where the fuse panel used to be, its failings gave it personality, even made it lovable. But its lovable personality isn’t the reason that the TRS-80 became the most popular of the trio of 1977, and remained the leading system until perhaps 1980 or 1981. No, that was because (unlike the Apple II, which cost $1300 for a 4 K system without a monitor) it was relatively cheap at $600, and because (unlike the Commodore PET, which was bedeviled by supply issues throughout 1977 and 1978) it was, at least after the initial surge of interest had convinced Radio Shack to begin manufacturing it in numbers, readily available at thousands of stores all over the country.

Realizing at last that there was gold in these here hills, Radio Shack began to relent with some of the penny pinching, gradually transforming the TRS-80 into a usable little system. The standard 4 K of RAM soon became a much more reasonable 16 K, and Leininger’s primitive BASIC was replaced with a much better Microsoft-licensed variant. (Early adapters got the privilege of paying to have their machines retrofitted with these enhancements; Radio Shack never took its munificence too far.) By the time the TRS-80 had its first birthday, disk drives had appeared, as had the possibility of further expanding RAM to as much as 48 K. Such options, which had never been part of the original design plan, required the purchase of a bulky expansion box to house them and were certainly not cheap, but they did exist and were gradually adopted by those who stuck with the platform.

But we’re getting ahead of ourselves. Let’s say it’s late 1977 or early 1978, and you’ve just brought your shiny new Trash-80 home. What might you do with it? I’ll talk about that next time, and in the process also discuss a program that’s much older than any I’ve talked about so far, but that holds an important place in the history of interactive narrative.

The Trash-80, Part 3
June 14, 2011

As computers began to enter homes in reasonable numbers in 1977 and 1978, bemused (or not so bemused) spouses, parents, children, siblings, and roommates all asked the same question: but what can you actually do with it? Proud new owners didn’t find that a very easy question to answer, for these machines were absurdly limited; the TRS-80 had no color capabilities, only the barest of graphical capabilities, no sound, no lower case letters, for God’s sake. (Radio Shack, in what should be becoming a familiar theme by now, refused to splurge for the $2.00 or so they would have cost to include.) It was not even possible to connect a printer to the TRS-80 prior to the arrival of Radio Shack’s expensive “expansion interface” in mid-1978. Even the staple justification of a few years later for buying a computer — “We can use it for word processing, and the kids can do their school reports on it” — wouldn’t quite fly with 1977-era machines.

The TRS-80 shipped with two programs on an accompanying cassette, computerized versions of backgammon and blackjack. Radio Shack also had four “productivity applications” already available at launch. There were, for starters, some educational software to help the kids out in math and a personal finance system (Quicken in 4 K!). There was also a payroll program, presumably the same one that French and Leininger had demonstrated to Charles Tandy, head of the company, to sell him on the potential of the TRS-80; the program crashed when Tandy enter an annual salary (his own) too large for it to handle.

And there was a “kitchen” utility bundle, which could convert measurements and store messages for other family members. This last demonstrates how confused even Radio Shack was about what their computer would actually get used for. They seemed quite high on the idea of a TRS-80 in the kitchen, often including pictures of exactly that in their promotional literature, yet one has to wonder just what advantage a balky computer with cassette-based storage offers over a calculator and a good old pencil and pad. Solutions like this, far more convoluted and time consuming than the traditional methods they wanted to replace, were everywhere in the early software market. Hard as Radio Shack and owners might have tried to justify the TRS-80 as a “serious” tool, it’s probably safe to say that virtually all who purchased them wanted first and foremost just to play with them. No wonder they shipped with two games as their standard software starter package.

Still, Radio Shack showed considerable foresight in realizing that their machine needed supporting software. They actively encouraged early adapters to provide it, making it known that they would sell the best efforts in their stores, a plan that worked rather brilliantly and doubtless contributed to the TRS-80’s having a much larger software library than its competitors from Apple and Commodore by 1979. While that pipeline was ramping up, though, users had to find other ways of making their TRS-80s do something. One possibility, of course, was to write their own programs. To support this approach, the TRS-80 shipped with a thorough and friendly BASIC tutorial written by David Lien that is still regarded as something of a classic of its genre today. Yet many craved complete, working programs that they could enter and run, if only to learn from them and to use them as a base from which to start off on their own BASIC explorations.

Luckily, they quickly found a substantial library of code from which to draw. By 1977 BASIC had been in active use on larger institutional computers for well more than a decade, resulting in a large library of programs just waiting to be keyed into all those new TRS-80s. In the very early months there were sharp limitations imposed by available memory and by a primitive implementation of BASIC, but with the arrival of 16 K machines and Level 2 BASIC it became possible to port most of the extant BASIC library to the TRS-80 with relatively little effort, as well as to move programs among the three otherwise incompatible home-computer models of the era. Thus BASIC became a lingua franca, a bridge among all of these very different machines (or, if you like, the Java of the late 1970s). Huge swathes of the BASIC code that users of machines like the HP-2100 series had been trading and tinkering with for years now made their way into bedrooms and living rooms. Suddenly the back catalog of programs previously published in places like Creative Computing had new significance. Showing perfect timing, the magazine had published two “best of” collections as books in 1976 and 1977, full of programs to enter and programming problems to solve; both books now began to sell very well indeed to a new audience of microcomputer owners. In 1978 Creative Computing published BASIC Computer Games, a revision of a book its founder David Ahl had first published in 1973. It included 101 games taken from the magazine’s first five years and before, born of places like the People’s Computer Company, and it became a huge hit, a touchstone for a whole generation of budding gamers and programmers.

Of the programs I discussed previously in this blog, Hunt the Wumpus along with its predecessor games made it onto the TRS-80 in fairly short order. The Oregon Trail initially did not, perhaps due to MECC beginning to realize it had a valuable property under its hands and beginning to claim copyright protections, but in its October, 1979, issue SoftSide magazine published something called Westward 1847, allegedly by one John C. Sherman. A quick look at the code reveals Westward to be our old friend The Oregon Trail with modifications to let it run on the TRS-80. As for Adventure… well, that was a much more complex program and also not written in BASIC, making it a tougher nut to crack. I’ll come back to that soon.

Also among the programs that now began appearing on these new microcomputers was a curious simulation of a psychotherapy session. More on that hugely important program and its legacy next time.

Eliza, Part 1
June 15, 2011

In 1965 a professor at MIT, Joseph Weizenbaum, introduced a computerized conversation simulator he called ELIZA. The most famous ELIZA transcript was published soon after in an article Weizenbaum wrote for the January, 1966, volume of Communications of the ACM. It is a record of a conversation between the program and a young woman; the program’s responses in the text below are in all caps.

Men are all alike.
IN WHAT WAY
They’re always bugging us about something or other.
CAN YOU THINK OF A SPECIFIC EXAMPLE
Well, my boyfriend made me come here.
YOU BOYFRIEND MADE YOU COME HERE
He says I’m depressed much of the time.
I AM SORRY TO HEAR YOU ARE DEPRESSED
It’s true. I am unhappy.
DO YOU THINK COMING HERE WILL HELP YOU NOT TO BE UNHAPPY
I need some help, that much seems certain.
WHAT WOULD IT MEAN TO YOU IF YOU GOT SOME HELP
Perhaps I could learn to get along with my mother.
TELL ME MORE ABOUT YOUR FAMILY
My mother takes care of me.
WHO ELSE IN YOU FAMILY TAKES CARE OF YOU
My Father.
YOUR FATHER
You are like my father in some ways.
WHAT RESEMBLANCE DO YOU SEE
You are not very aggressive but I think you don’t want me to notice that.
WHAT MAKES YOU THINK I AM NOT VERY AGGRESSIVE
You don’t argue with me.
WHY DO YOU THINK I DON’T ARGUE WITH YOU
You are afraid of me.
DOES IT PLEASE YOU TO BELIEVE I AM AFRAID OF YOU
My father is afraid of everybody.
WHAT ELSE COMES TO MIND WHEN YOU THINK OF YOUR FATHER
Bullies.
DOES THAT HAVE ANYTHING TO DO WITH THE FACT THAT YOUR BOYFRIEND MADE YOU COME HERE

It is often assumed that “Eliza” is simply the name of the psychotherapist with which the human “patient” converses, but this is not in fact the case. ELIZA is actually the name of a generalized conversation system of Weizenbaum’s devising, being a reference to a working-class character in George Bernard Shaw’s play Pygmalion who learns to speak in an upper-class diction in spite of her origins. The metaphor, then, is that the computer has traded in the inflexible diction of a programming language for everyday natural language. Different “scripts” could be plugged into ELIZA to represent different characters. The first of these to be developed by Weizenbaum, as well as the one that generated the transcript above and the one that everyone remembers today, was called simply “Doctor.” In the film Rebel at Work Weizenbaum describes the process that led him to this rather brilliant character choice:

“And then all of a sudden it came to me: the psychiatrist. The psychiatrist asks questions in response to what the patient says. It may be partially or totally irrelevant, but the patient will interpret his words in terms of his own frame of mind. The patient assumes that the psychiatrist knows something, that he understands, that there is some sense to his words. ‘I don’t know what it is yet, but it’s not nonsense.’ And that’s how it started — then came ELIZA.

‘Well,’ says the psychiatrist, ‘perhaps… what does this remind you of?’

‘Hmm, very clever!’ thinks the patient. ‘This is a psychiatrist who really knows what I feel. I’m going to continue working with him.'”

As Weizenbaum was careful to describe in his article, in no sense does ELIZA actually understand anything its interlocutor enters. It is simply an elaborate text-generation engine, which searches for patterns in the entered text which can serve as hooks to be manipulated and recombined into its responses. The genius of the “Doctor” script is that this is also essentially what a psychotherapist often does during a session, at least from the perspective of the layman. Weizenbaum did prepare at least a few other ELIZA scripts, such as (keeping with the mental health theme) one for a paranoid schizophrenic, but these apparently did not have quite the same magic, and aren’t much remembered today. UPDATE: Actually, as Nick points out in the comments below, we have no evidence that Weisenbaum developed any scripts other than “Doctor.”

Even if we confine ourselves to “Doctor,” the famous script I included above is something of a best-case scenario. Weizenbaum, usually quite sober about these things, was stretching the truth considerably when he called it a “typical conversation” in his article. There inevitably comes a point in any ELIZA session that continues for any length of the time when the programs says something that clearly reveals it to be the elaborate parlor trick that it really is. Such breakdowns are at least as common as the several surprisingly apropos responses in the transcript above.

Weizenbaum wrote ELIZA in Lisp, a somewhat esoteric programming language developed at MIT for artificial intelligence and natural language processing applications. UPDATE: Make that MAD-SLIP, which originated at the University of Michigan. See Nick’s comment below for more details. However, his detailed ACM article served the same purpose as did Don Woods’s meticulously commented Adventure source code of ten years later, making the porting of ELIZA to other platforms and languages a relatively straightforward task. In the process, Weizenbaum’s original concept of a generalized conversation engine was forgotten, and ELIZA the system became Eliza the female psychotherapist. Creative Computing published a version in BASIC by Jeff Shrager and Steve North in its July/August, 1977, issue. In North’s words, “Although the program is an inferior imitation of the original, it does work.” Its limitations in comparison with Weizenbaum’s original derive from being written in BASIC and from the necessity of running in just 16 K of RAM. It’s nevertheless impressive in its way for what it is, and would serve as a springboard for countless sequels and derivations over the next decade. It seemed no one could own a microcomputer in the 1970s or 1980s without having some sort of Eliza variant somewhere in their software collection.

If you’d like to try out this version of Eliza on a virtual TRS-80, you can do so using the SDLTRS emulator and this state file.

1. Make sure the Level 2 ROM file and the NewDOS boot disk are in the emulator’s root directory, and that the state file is in some known location.
2. Start the emulator.
3. Turn your caps-lock on.
4. Press ALT-L to load a state.
5. Navigate to the state file and select it.

You’ll find yourself at a BASIC READY prompt, from which you can LIST the program, edit it, and of course RUN it. (Yes, it is very, very slow; such is life when doing lots of string processing in BASIC on a 1.78 MHz machine.) Type “SHUT” at any prompt to quit the program — and remember, you must have your caps lock on for it to “understand” you.

Finally, for those who know how to deal with such things, I’ve also made available the tokenized TRS-80 BASIC file of Eliza.

So, having talked about what ELIZA is we can soon get to the more interesting questions of how it works and what it means — and why I felt compelled to backtrack this way in the first place.

Postscript (June 17, 2011):

I’ve grown disenchanted with the SDLTRS emulator, and decided to use the one included with the MESS project from now on. Here’s a state file for use with that emulator. See my recently revised post on emulating the TRS-80 for more details on how to get a virtual TRS-80 working under MESS.

Eliza, Part 2
June 16, 2011

Just to be sure we understand what Eliza does and doesn’t do, I thought it might be instructive to look at an actual conversation from under the hood. What follows is an only slightly modified version of the sample run included in the July/August, 1977, issue of Creative Computing that introduced the BASIC Eliza. (Specifically, I changed the original reference to an IMSAI 8080 to a Tandy in keeping with this blog’s recent theme.) It’s a much less compelling example than the famous transcript I included in my last post, which is partly down to the acknowledged inferiority of this version of Eliza and partly down to Creative Computing choosing to interact the way a person more typically might — i.e., by trying to take the piss out of the program just a bit rather than playing along with the psychologist / patient relationship. In that sense I’d call it a more honest reflection of Eliza‘s capabilities and limitations, and of the average user’s experience with it.

At the heart of the program is a routine that searches each input for one of a group of text sequences. In order of priority, they are:

1. “CAN YOU”
2. “CAN I”
3. “YOU ARE”
4. “YOU’RE”
5. “I DON’T”
6. “I FEEL”
7. “WHY DON’T YOU”
8. “WHY CAN’T I”
9. “ARE YOU”
10. “I CAN’T”
11. “I AM”
12. “I’M ”
13. “YOU ”
14. “I WANT”
15. “WHAT”
16. “HOW”
17. “WHO”
18. “WHERE”
19. “WHEN”
20. “WHY”
21. “NAME”
22. “CAUSE”
23. “SORRY”
24. “DREAM”
25. “HELLO”
26. “HI ”
27. “MAYBE”
28. ” NO”
29. “YOUR”
30. “ALWAYS”
31. “THINK”
32. “ALIKE”
33. “YES”
34. “FRIEND”
35. “COMPUTER”

As soon as one of these sequences is found, it is taken as the key sequence for the input as a whole, and no more searching is done. In other words, “COMPUTER” could be taken as the key sequence only if the input text does not contain any of the previous 34 sequences.

RUN
HI! I'M ELIZA. WHAT'S YOUR PROBLEM?
? I AM AN IBM 370
DID YOU COME TO ME BECAUSE YOU ARE AN IBM 370

When Eliza finds a key sequence, it responds with a set sequence of its own. In this case, it has latched onto the sequence “I AM” in the input. Having done so, it automatically throws away all of the input through that point, leaving just “AN IBM 370.” It then looks up the appropriate response pattern, which is “DID YOU COME HERE BECAUSE YOU ARE…”, followed by the remainder of the original input.

(Oh, and just so everyone gets the joke: an IBM 370 was an extremely large and powerful mainframe computer of the era; thus its repeated talking down to the little Radio Shack microcomputer.)

? YES I WANT A NEW LINEPRINTER
WHAT WOULD IT MEAN TO YOU IF YOU GOT A NEW LINEPRINTER

This time there are two possible matches: “YES” and “I WANT.” However, “I WANT” has higher priority, so Eliza throws away all of the input text through that point, which incidentally includes the “YES.” The appropriate response to “I WANT” is “WHAT WOULD IT MEAN TO YOU IF YOU GOT…”, followed by the remainder of the input.

? ABOUT 1800 LPM
SAY, DO YOU HAVE ANY PSYCHOLOGICAL PROBLEMS?

We’ve given Eliza nothing to latch onto here; no sequence matches at all. Therefore it falls back on a canned response for such situations.

? WHAT WOULD YOU KNOW I'M A 370 AND YOU'RE A TANDY
WHAT MAKES YOU THINK I AM A TANDY

There are a few matches this time, but “YOU’RE” has the highest priority, so Eliza throws everything away up to that point and appends the remainder to the appropriate response, “WHAT MAKES YOU THINK I AM…”

? IT SAYS THAT ON YOUR FRONT PANEL
WHY ARE YOU CONCERNED ABOUT MY FRONT PANEL

Key: “YOUR”
Result: “WHY ARE YOU CONCERNED ABOUT MY…” + “FRONT PANEL”

? LOOK YOU BROUGHT UP THE SUBJECT
WE WERE DISCUSSING YOU-- NOT ME.

Not all response sequences incorporate the original input. In this case, the key “YOU ” results in the canned response “WE WERE DISCUSSING YOU– NOT ME.”

? I'M FIXING A HOLE...
DID YOU COME HERE BECAUSE YOU ARE FIXING A HOLE...

The key sequence this time is “I’M “. Eliza turns to the same response sequence for both “I AM” and “I’M “, as one might expect.

? SORRY THAT WAS A TEN YEAR OLD SOFTWARE BUG
PLEASE DON'T APOLOGIZE

Key: “SORRY”
Result: “PLEASE DON’T APOLOGIZE!”

(Presumably, this is — leaving aside the obvious Beatles reference — an in-joke having to do with the IBM 370. If anyone reading this knows what exactly is being referred to here, by all means enlighten us in the comments.)

? I AM ALWAYS APOLOGIZING
HOW LONG HAVE YOU BEEN ALWAYS APOLOGIZING

Yet again “I AM” is the key sequence. However, notice that the response is not quite the same. For most keys, Eliza cycles through several response sequences, hopefully masking somewhat the automated nature of the whole process. In the case of “I AM,” there are four possible responses. (Due to an idiosyncrasy in the program, synonyms such as “I AM” and “I’M” are each run through their own cycle even though they draw from the same list of responses.)

? SINCE MY FIRST COLD START
WHAT DOES THAT SUGGEST TO YOU?

Once again we have given Eliza nothing to go on, so it falls back on the second of seven possible noncommittal responses.

? YOU'RE THE SHRINK
DOES IT PLEASE YOU TO BELIEVE I AM THE SHRINK

Our second use of “YOU’RE” results in the second of four possible responses to that sequence.

? DON'T YOU KNOW?
OH, I KNOW?

And our second use of “YOU ” results in the second of three possible response to that sequence.

? I AM BEGINNING TO WONDER ABOUT YOU
DO YOU BELIEVE IT IS NORMAL TO BE BEGINNING TO WONDER ABOUT I

Here we have the first real breakdown, and it’s an illustrative failure indeed. Eliza discovered yet another use of “I AM,” our third now, and so turns to the third response, “DO YOU BELIEVE IT IS NORMAL TO BE…” Based on what we’ve seen so far, we might expect the full reply to be, “DO YOU BELIEVE IT IS NORMAL TO BE BEGINNING TO WONDER ABOUT YOU,” which is obviously inappropriate. To account for situations like this, Eliza always attempts to modify the input-text fragments that it reprints, by changing first-person pronoun references to second-person and vice versa, and attempting to do some simplistic to-be verb conjugation. To be precise, it replaces sequences in the input text like so:

” AM ” <--> ” ARE ”
“WAS ” <--> “WERE ”
” I ” <--> ” YOU ”
“MY ” <--> “YOUR ”
” I’VE ” <--> ” YOU’VE ”
” I’M ” <--> ” YOU’RE ”

Eliza has in fact been searching reprinted fragments all along for these sequences, but has not found any until now. And now that it does, it gets it wrong, falling afoul of the fact that in English the second-person pronoun is the same in both the nominative and the accusative, but the first-person pronoun is different. Since it lacks any structural understanding of the English language and can only replace sequences of characters with other sequences, it replaces “YOU” with “I” rather than “ME.”

? HA HA HA YOU CAN'T EVEN TALK PROPERLY
YOU'RE NOT REALLY TALKING ABOUT ME, ARE YOU?

Key: “YOU ”
Result: “YOU’RE NOT REALLY TALKING ABOUT ME, ARE YOU?” (response 3 of 3)

? IS THERE ANYONE ELSE IN THE ROOM?
I SEE

Key: none
Result: Noncommittal response 3 of 7.

? COMPUTERS DON'T HAVE EYES
ARE YOU SURE?

Here we have another “failure” of sorts that this time actually works within the context of the conversation. Eliza takes the sequence “YES” from the word “EYES” as its key, resulting in the first of three possible responses to that sequence. Considering the non-sequitur that might have resulted, Eliza just dodged a bullet.

? ABOUT COMPUTERS?
DO COMPUTERS WORRY YOU?

Key: “COMPUTER”
Result: “DO COMPUTERS WORRY YOU?” (response 1 of 7)

? SHOULD THEY AFTER ALL I AM A 370
DO YOU ENJOY BEING A 370

Key: “I AM”
Result: “DO YOU ENJOY BEING” + “A 370” (response 4 of 4)

…and so on. I’m sure you get the gist of it by now. Having beaten this particular dead horse into the ground, I’ll wrap up this topic next time by talking about what the experience of Eliza ultimately means — to me, to Joseph Weizenbaum, and maybe to you.

Eliza, Part 3
June 21, 2011

The most obvious legacy of Eliza is the legions of similar chatterbots which have followed, right up to the present day. But what does Eliza mean to the history of interactive narrative? Or, put another way: why did I feel the need to backtrack and shoehorn it in now?

One answer is kind of blindingly obvious. When someone plays Eliza she enters into a text-based dialog with a computer program. Remind you of something? Indeed, if one took just a superficial glance at an Eliza session and at a session of Adventure one might assume that both programs are variations on the same premise. This is of course not the case; while Eliza is “merely” a text-generation engine, with no deeper understanding, Adventure and its antecedents allow the player to manipulate a virtual world through textual commands, and so cannot get away with pretending to understand the way that Eliza can. Still, it’s almost certain that Will Crowther would have been aware of Eliza when he began to work on Adventure, and its basic mode of interaction may have influenced him. Lest I be accused of stretching Eliza‘s influence too far, it’s also true that almost all computer / human interaction of the era was in the form of a textual dialog; command-line interfaces ruled the day, after all. The really unique element shared by Eliza and Adventure was the pseudo-natural language element of that interaction. Just on that basis Eliza stands as an important forerunner to full-fledged interactive fiction.

But to just leave it at that, as I’m afraid I kind of did when I wrote my little history of IF a number of years ago now, is to miss most of what makes Eliza such a fascinating study. At a minimum, the number of scholars who have been drawn to Eliza despite having little or no knowledge of or interest in its place in the context of IF history points to something more. Maybe we can tease out what that might be by looking at Eliza‘s initial reception, and at Joseph Weizenbaum’s reaction to it.

Perhaps the first person to interact extensively with Eliza was Weizenbaum’s secretary: “My secretary, who had watched me work on the program for many months and therefore surely knew it to be merely a computer program, started conversing with it. After only a few interchanges with it, she asked me to leave the room.” Her reaction was not unusual; Eliza became something of a sensation at MIT and the other university campuses to which it spread, and Weizenbaum an unlikely minor celebrity. Mostly people just wanted to talk with Eliza, to experience this rare bit of approachable fun in a mid-1960s computing world that was all Business (IBM) or Quirky Esoterica (the DEC hackers). Some, however, treated the program with a seriousness that seems a bit baffling today. There were even suggestions that it might be useful for actual psychotherapy. Carl Sagan, later of Cosmos fame, was a big fan of this rather horrifying idea, which a group of psychologists actually managed to get published as a serious article in The Journal of Nervous and Mental Diseases:

Further work must be done before the program will be ready for clinical use. If the method proves beneficial, then it would provide a therapeutic tool which can be made widely available to mental hospitals and psychiatric centers suffering a shortage of therapists. Because of the time-sharing capabilities of modern and future computers, several hundreds patients an hour could be handled by a computer system designed for this purpose. The human therapist, involved in the design and operation of the system, would not be replaced, but would become a much more efficient man since his efforts would no longer be limited to the one-to-one patient-therapist as now exists.

Weizenbaum’s reaction to all of this has become almost as famous as the Eliza program itself. When he saw people like his secretary engaging in lengthy heart-to-hearts with Eliza, it… well, it freaked him the hell out. The phenomenon Weizenbaum was observing was later dubbed “the Eliza effect” by Sherry Turkle, which she defined as the tendency “to project our feelings onto objects and to treat things as though they were people.” In computer science and new media circles, the Eliza effect has become shorthand for a user’s tendency to assume based on its surface properties that a program is much more sophisticated, much more intelligent, than it really is. Weizenbaum came to see this as not just personally disturbing but as dangerous to the very social fabric, an influence that threatened the ties that bind us together and, indeed, potentially threatened our very humanity. Weizenbaum’s view, in stark contrast to those of people like Marvin Minsky and John McCarthy at MIT’s own Artificial Intelligence Laboratory, was that human intelligence, with its affective, intuitive qualities, could never be duplicated by the machinery of computing — and that we tried to do so at our peril. Ten years on from Eliza, he laid out his ideas in his magnum opus, Computer Power and Human Reason, a strong push-back against the digital utopianism that dominated in many computing circles at the time.

Weizenbaum wrote therein of his students at MIT, which was of course all about science and technology. He said that they “have already rejected all ways but the scientific to come to know the world, and [they] seek only a deeper, more dogmatic indoctrination in that faith (although that word is no longer in their vocabulary).” He certainly didn’t make too many friends among the hackers when he described them like this:

Bright young men of disheveled appearance, often with sunken glowing eyes, can be seen sitting at computer consoles, their arms tensed and waiting to fire their fingers, already poised to strike, at the buttons and keys on which their attention seems to be riveted as a gambler’s on the rolling dice. When not so transfixed, they often sit at tables strewn with computer printouts over which they pore like possessed students of a cabbalistic text. They work until they nearly drop, twenty, thirty hours at a time. Their food, if they arrange it, is brought to them: coffee, Cokes, sandwiches. If possible, they sleep on cots near the printouts. Their rumpled clothes, their unwashed and unshaven faces, and their uncombed hair all testify that they are oblivious to their bodies and the world in which they move.

Although Weizenbaum claimed to be basing this description at least to some extent on his own experiences of becoming too obsessed with his work, there’s some evidence that his antipathy for the hardcore hackers at MIT was already partially in place even before Eliza. It’s worth noting that Weizenbaum chose to write Eliza not on the hackers’ beloved DEC, but rather on a big IBM 7094 mainframe located in another part of MIT’s campus; according to Steven Levy, Weizenbaum had “rarely interacted with” the hardcore hacker contingent.

Still, I’m to a large degree sympathetic with Weizenbaum’s point of view. Having watched a parade of young men come through his classes who could recite every assembler opcode on the PDP but had no respect or understanding of aesthetics, of history, of the simple good fellowship two close friends find over a bottle of wine, he pleads for balance, for a world where those with the knowledge to create and employ technology are also possessed of humanity and wisdom. It’s something we could use more of in our world of Facebook “friends” and Twitter “conversations.” I feel like Weizenbaum every time I wander over to Slashdot and its thousands of SLNs — Soulless Little Nerds, whose (non-videogame) cultural interests extend no further than Tolkien and superheroes, who think that Sony’s prosecution of a Playstation hacker is the human-rights violation of our times. It’s probably the reason I ended up studying the humanities in university instead of computer science; the humanities people were just so much more fun to talk with. I’m reminded of Watson’s initial description of his new roommate Sherlock Holmes’s character in A Study in Scarlet:

1. Knowledge of literature — nil.
2. Knowledge of philosophy — nil.
3. Knowledge of astronomy — nil.
4. Knowledge of politics — feeble.
5. Knowledge of botany — variable. Well up in belladonna, opium and poisons generally. Knows nothing of practical gardening.
6. Knowledge of geology — practical, but limited. Tells at a glance different soils from each other. After walks, has shown me splashes upon his trousers and told me by their color and consistence in what part of London he has received them.
7. Knowledge of chemistry — profound.
8. Knowledge of anatomy — accurate, but unsystematic.
9. Knowledge of sensational literature — immense. He appears to know every detail of every horror perpetuated in the century.
10. Plays the violin well.
11. Is an expert singlestick player, boxer, and swordsman.
12. Has a good practical knowledge of English law.

No wonder Watson moved out and Arthur Conan Doyle started adjusting his hero’s character pretty early on. Who’d want to live with this guy?

All that aside, I also believe that, at least in his strong reaction to the Eliza effect itself, Weizenbaum was missing something pretty important. He believed that his parlor trick of a program had induced “powerful delusional thinking in quite normal people.” But that’s kind of an absurd notion, isn’t it? Could his own secretary, who, as he himself stated, had “watched [Weizenbaum] work on the program for many months,” really believe that in those months he had, working all by himself, created sentience? I’d submit that she was perfectly aware that Eliza was a parlor trick of one sort or another, but that she willingly surrendered to the fiction of a psychotherapy session. It’s no great insight to state that human beings are imminently capable of “believing” two contradictory things at once, nor that we willingly give ourselves over to fictional worlds we know to be false all the time. Doing so is in the very nature of stories, and we do it every time we read a novel, see a movie, play a videogame. Not coincidentally, the rise of the novel and of the movie were both greeted with expressions of concern that were not all that removed from those Weizenbaum expressed about Eliza.

There’s of course a million philosophical places we go could with these ideas, drawing from McLuhan and Baudrillard and a hundred others, but we don’t want to entirely derail this little series on computer-game history, do we? So, let’s stick to Eliza and look at what Sherry Turkle wrote of the way that people actively helped along the fiction of a psychotherapy session:

As one becomes experienced with the ways of Eliza, one can direct one’s remarks either to “help” the program make seemingly pertinent responses or to provoke nonsense. Some people embark on an all-out effort to “psych out” the program, to understand its structure in order to trick it and expose it as a “mere machine.” Many more do the opposite. I spoke with people who told me of feeling “let down” when they had cracked the code and lost the illusion of mystery. I often saw people trying to protect their relationships with Eliza by avoiding situations that would provoke the program into making a predictable response. They didn’t ask questions that they knew would “confuse” the program, that would make it “talk nonsense.” And they went out of their way to ask questions in a form that they believed would provoke a lifelike response. People wanted to maintain the illusion that Eliza was able to respond to them.

If we posit, then, that Eliza‘s interactors were knowingly suspending their disbelief and actively working to maintain the fiction of a psychotherapy session, the implications are pretty profound, because now we have people in the mid-1960s already seriously engaging with a digital “interactive fiction” of sorts. We see here already the potential and the appeal of the computer as a storytelling medium, not as a tool to create stories from whole cloth. Eliza‘s interlocutors are engaging with a piece of narrative art generated by a very human artist, Weizenbaum himself (not that he would likely have described himself in those terms). This is what story writers and story readers have always done. Unlike Weizenbaum, I would consider the reception of Eliza not a cause for concern but a cause for excitement and anticipation. “If you think Eliza is exciting,” we might say to that secretary, “just wait until the really good stuff hits.” Hell, I get retroactive buzz just thinking about it.

And that buzz is the real reason why I wanted to talk about Eliza.

Adventureland, Part 1
June 22, 2011

Scott Adams occupies an odd position in interactive fiction in that he tends to get more love from those outside the active modern community than from those within it. Every year brings one or two fawning interviews with the always obliging Mr. Adams on mainstream or retro-gaming sites. Within the IF community, however, Adams’s works are usually mentioned, if at all, only as historical curiosities, and certainly aren’t accorded even a sliver of the respect given to the Infocom canon, outside of a handful of reactionary voices who declare this lack of respect for Adams’s simplistic but fun games to be symptomatic of the general literary pretensions of the community as a whole that have made the modern text adventure a No Fun Allowed zone. (For a classic and entertaining rant in this vein, see the discussion page of the Adventureland Wikipedia entry.) Further confusing the issue is an unfortunate if blessedly only occasional tendency toward self-aggrandizement on Adams’s own part, such as the FAQ entry on his home page that states he is “credited [by whom?] with starting the entire multi billion dollar a year computer game industry.” “Helping to start” I would be fine with, but as it stands… really, Scott? You singlehandedly started the computer-game industry?

Still, Adams does deserve more credit and respect than he generally receives within community circles for bringing text adventures into homes for the first time and, not incidentally, showing that one could make a pretty good living from the things. His creation of a playable adventure game on a TRS-80 with just 16 K of RAM and a cassette drive was conceptually audacious and technically impressive, and that he did it in the slow, inefficient TRS-80 BASIC just made it even more remarkable. Adams’s greatest failing in the long run was perhaps his inability to make the transition from treasure-hunting text adventures to the more sophisticated storytelling of Infocom’s interactive fiction, as evidenced by his seeming disinterest in improving the core technology of his games beyond gilding these simplistic lillies with graphics and colors. But that’s material for later posts. Today I want to talk about Adams’s initial masterstroke, Adventureland.

Born in 1952, Adams already had extensive professional experience with computers before he created Adventureland in 1978, having majored in the field at the Florida Institute of Technology, worked with computers during a stint in the Navy, and found employment thereafter with Stromberg-Carlson, an early manufacturer of telephone PBX equipment, as a programmer. Adams had also been building and experimenting with microcomputers in his home since 1975, when he built a Sphere 1 from a kit. Beginning with a tic-tac-toe game which “could never lose,” his main activity with these machines had been writing and playing games. Like so many other hackers, he was entranced when Adventure turned up on the computer at his workplace, and, also like so many others, after completing it at last he turned his attention to writing his own. But unlike the others, who did their work on big institutional computers, Adams chose the little TRS-80 as his target platform.

Adams did not set out with grand ideas about bringing interactive narrative to the masses. In standard hacker fashion, he was drawn to the project as an interesting technical challenge in light of the constraints of the TRS-80, and as a chance to work extensively with text, something he hadn’t done previously. As an experienced programmer, Adams shared most hackers’ preference for creating robust, reusable systems and tools in lieu of one-off programs, and so began working not so much on an adventure game as on a reusable adventure implementation system. He thus divided the project into three parts: a database editor of sorts to let him input the data that would make up the virtual world of each game, an interpreter to read in that data and let the player interact with it, and finally the data that made up the game itself.

It’s a remarkable system, but it also should be understood that Adams did not create a full-fledged virtual machine in the sense of Infocom’s later Z-Machine. While the interpreter does indeed read in the details of rooms, objects, etc., much functionality is hard-coded into the BASIC interpreter. The engine, for instance, assumes that gameplay will revolve around gathering a collection of objects (treasures) and dropping them back in a certain location. Any but the most basic modifications to the Adventureland game will also require modifying the code of the interpreter, if only because the name of the game itself and instructions for play are hard-coded there.

It’s really a hybrid system, surprisingly similar in its construction to Adventure itself, which also divided its functionality between the program code and a data file.

In fact, having just played through the original Adventureland I’m struck by how many similarities it bears to its predecessor. Like Adventure, Adventureland is a plot-less treasure hunt that begins above-ground in a forest.

Adventureland‘s wilderness area is actually larger and more interesting than Adventure‘s, containing a number of puzzles in its own right beyond the obvious one of finding one’s way underground. Its underground complex is, however, vastly smaller, as one would expect given the constraints Adams was working under. This is not entirely to the game’s disadvantage, as Adams’s inability to indulge himself with dozens of empty locations keeps things much more tightly focused and manageable for the player; the obligatory maze, for example, consists of a modest six rooms, a marked and welcome contrast to Adventure‘s monstrosities.

Which is not to say that Adventureland is exactly playable, at least by modern standards. The above-ground areas are filled with the usual non-reversable room connections that make mapping and navigation a non-intuitive pain, redeemed (once again) only by the fact that there are so few locations in all. The logistics of light sources and inventory management are once again a big part of the challenge, and there are heaps of ways to screw up and make the game unwinnable, many unhinted at before they happen. To understand the full cruelty of this, you have to put yourself in the shoes of someone playing the game on an actual TRS-80, where it is only possible to restore a saved position by restarting the game entirely from cassette, a process that takes about 25 minutes. Saving a game, meanwhile, takes over 4 minutes. No wonder Adams could advertise that Adventureland would take weeks or months to complete! What he didn’t mention was that in addition to a TRS-80 it would require the patience of Job…

I notice the same dichotomy in Adventureland‘s puzzles that I wrote about with respect to Adventure‘s: most are either very straightforward and commonsensical or unfair to the point of absurdity, with only a few occupying a satisfying middle ground. Also like Adventure, Adventureland is surprisingly progressive in some ways, managing to shoehorn a fair number of hints into its 16 K, but also leaves some of its worst offending puzzles totally unclued. An example is the bear puzzle (a character whose presence is yet another echo of Adventure). He is blocking your way, and can be moved only by the completely unmotivated action of YELLing. Later versions did allow the player to SCREAM at the bear (see Grunion Guy’s review for an hilarious anecdote related to that), but in this original version it was YELLing or nothing.

To make this puzzle even worse, the bear is described as “looking hungry.” This naturally leads the player to want to feed him the honey which she can find elsewhere in the game, which in fact works — except that said honey is also a treasure (?!) she needs to collect to finish the game. Not only is all this supremely cruel, but, just to make it all worse, the false solution actually makes for a much fairer and more satisfying puzzle than the correct one.

Granted, Adventureland‘s extremely primitive parser and world model do once again perhaps make it difficult to build really challenging puzzles that don’t spill over into unfairness. Its implementation of the THROW verb is quite interesting, as it already shows Adams struggling with the limitations of his two-word parser.

It’s not really fair to judge Adventureland‘s text by literary standards, since every “the” and “a” use precious memory (and thus were often dropped entirely). Still, Adams does at times achieve a sort of minimalist poetry.

He does have some issues with spelling…

…but there’s a sort of goofy charm about the whole experience…

…which finally comes down to this.

And that’s about all there is to say about it, really. There are no advances over the treasure-hunt template laid down by Adventure, but Adventureland is an impressive achievement merely for existing, and even today is still kind of fun in its simple way.

If you’d like to play it for yourself, there are plenty of ways to do so, the most accessible of which is a browser-based Java version at FreeArcade. Scott Adams himself hosts downloadable versions on his website. Or, if you want the most authentic experience possible, I have a MESS TRS-80 saved state that will let you play the original BASIC version on its original (virtual) hardware. (See my notes on MESS TRS-80 emulation to get started.)

Next time I’ll talk about Adventureland‘s marketing and reception and the TRS-80 adventure-game craze it started.

Adventureland, Part 2
June 24, 2011

The idea of a computer program as a salable artifact that one purchases like one would a book or record album was still quite a new one in 1978. In the world of institutional computing, commercial software was largely confined to operating systems and the most complicated, critical applications such as compilers, and was created and sold by the same companies that produced the hardware on which it ran; TOPS-10 was a product of DEC itself, Time-Shared BASIC a product of Hewlett-Packard, etc. These programs were sold not as individual products with fixed price tags, but rather negotiated as part of complicated contracts that also involved the hardware to run them and the personnel to support them. Software created by end-users of these machines was often so specialized as to be useless outside of the site where it was created, and where this was not the case was distributed freely. Since there was no real commercial market for stand-alone software, there was no incentive to do anything else.

That began to change virtually from the moment that the microcomputer age began. The first piece of standalone microcomputer commercial software was created by the company that would (for better or for worse) become synonymous with the closed-source commercial model of software distribution: Microsoft. That company’s first product, created in 1975 while Bill Gates and Paul Allen were still scruffy university students, was a version of BASIC sold on paper tape for the Altair 8800 kit computer. On February 3, 1976, Gates sent an “open letter to hobbyists” that has since become famous. In it he derided the widespread copying of Microsoft’s software, noting that, while seemingly every Altair owner was using BASIC, fewer than 10% had actually bought it, and claiming that he and Allen’s financial reward for their time spent developing it amounted to less than $2.00 per hour. Hobbyists reacted to the letter with surprise and a fair amount of outrage. It’s probably fair to say that the concept of software that was not free distributable, and thus the very idea of software “piracy,” had never occurred to them, so antithetical was it to the ethos of sharing and open information exchange of places like the Homebrew Computer Club. One Jim Warren replied:

There is a valid alternative to the problems raised by Bill Gates in his irate letter to computer hobbyists concerning “ripping off” software. When software is free, or so inexpensive that it’s easier to pay for it than to duplicate it, then it won’t be “stolen.”

Note the use of quotations around “ripping off” and “stolen,” as if these concepts in relation to software are farcical. The debate touched off by Gates and Warren still rages to this day. It’s also a morass I know better than to wade into here. Suffice to say that after Altair BASIC the proverbial cat was out of the bag, and software distribution was changed forever.

As I noted in an earlier post, Radio Shack was wise enough to realize that good software support was very important to the success of its new computer (an obvious fact that Commodore, among others, never seemed to fully grasp). Since almost all TRS-80s were sold from Radio Shack stores, the company had a great opportunity to create that support by encouraging submissions from hobbyists programmers and selling the best right alongside the computers themselves. It’s therefore kind of odd that most of the best and most interesting TRS-80 programs were not published by Radio Shack. Presumably the drawbacks of dealing with a huge, faceless corporation’s acquisitions department outweighed the distribution advantages.

The main facilitator of software distribution in this era was instead rather surprising: the magazines. Creative Computing had of course been publishing program listings in BASIC for years before the arrival of the TRS-80 and its competitors, and continued to do so now. And with an October, 1978, issue SoftSide magazine, the first TRS-80-specific magazine and I believe the first platform-specific magazine of any stripe, began publication with this mission statement:

Our intention is to publish software — and lots of it, free for the transcription. Every month we will offer programs for business, games, programs with household applications, even educational programs for children that will allow your home computer to become the educational aid we always knew it could be. Our content will be as diverse and unique as our featured programs’ writers.

Of course, that “transcription” made for one hell of a pain; laboriously typing in the hundreds of lines of code for some of the surprisingly complex programs that SoftSide published was No Fun, no matter how enamored you were with your new computer — and that’s not even considering the subtle bugs that could be introduced by getting a letter or a digit wrong here or there. Therefore SoftSide also sold an optional accompanying cassette for each issue, which contained all the programs published therein.

But that was only the beginning. Even before the birth of the magazine, SoftSide‘s publishers had formed The TRS-80 Software Exchange as a distribution organ for commercial software. In fact, the cynical might say that they formed Softside largely to promote TSE; each issue devoted a considerable number of pages to catalog listings of TSE’s titles, with the most commercially promising also being accorded individual half- or full-page spreads. In a sense, TSE was one of the first software publishers — but only in a sense. Publishing with TSE carried an advantage developers would kill for today:

You retain the rights to the programs you worked so hard to write. If your programs don’t sell, you don’t make money, so why tie up your software with an exclusive contract? With SoftSide, you’re free to market through us, and still sell your programs privately or through other non-exclusive arrangements. We prefer to let our performance be the only “tie that binds.”

What a deal, eh? No wonder so many hobbyists programmers desperate to get their programs into the hands of the masses and earn a little scratch along the way rushed to send in their creations. Scott Adams was among them; even before coding Adventureland he released a “3D tic-tac-toe” and a backgammon game through TSE. And like many others, he took full advantage of TSE’s generous terms by releasing as well through Creative Computing Software, a similar organ set up by that magazine, and also by selling what he could on his own. (For some fun anecdotes about what that was like, check out Matt Barton’s interview with Adams.) All of this occurred fully a year before Adams founded Adventure International, a real software publisher of his own. Adventureland first appeared in SoftSide‘s January, 1979, issue, being sold for $24.95 in tandem with a second adventure Scott had already written by that time with his then-wife, Alexis. Called Pirate Adventure, this game is both easier and more fondly remembered by most players than Adventureland itself.

It’s amusing to look back today on how naive and clumsy the early commercial game market was. Adams and TSE can’t even seem to settle on a name. In addition to its (presumably) real name, Adventureland appears in TSE advertisements as simply Adventure (now that’s a recipe for confusion!) or, my favorite, the evocative and enticing Land Adventure. (Well, I guess it’s factually accurate…) The second game, meanwhile, vacillates among Pirate Adventure, Pirate’s Adventure, and Pirate’s Cove.

But none of that mattered a jot. Adams’s adventures were absolutely unique, and they were being sold into a growing market hungry for interesting and entertaining new games. Most TRS-80 owners had no access to the large institutional machines that ran the original Adventure, making Adams’s games their first exposure to the form, the bridge that brought the innovations of Crowther and Woods to the burgeoning world of home computing. Like all those PDP-10 hackers, once they had solved Adams’s games many TRS-80 programmers started thinking about how to create their own. And so a genre was well and truly born.

Dog Star Adventure
June 28, 2011

Flipping through early issues of SoftSide magazine, one can’t help but notice a handful of people who are absolutely everywhere, churning out games, tools, applications, even feature articles at a dizzying pace. There’s Scott Adams, of course, who in addition to his adventures also wrote a variety of other card- and board-game adaptations and simple strategy games. There’s the Reverend George Blank, who in addition to editing the magazine and writing a pile of games and utilities for it also authored an article speculating on the possibilities for computer gaming:

Few good computer games have been written so far. Of the good ones, some are adaptations of games like chess and Othello [also known as Reversi] which existed first in another form. These games are good if they add a dimension to the play of the game that is not present in its original form (such as the possibility of solo play), and do so in an aesthetically pleasing form. My personal opinion is that such computer adaptations will play a trivial role in the future of computer games and the best ones will be those which take unique advantage of the computer’s capabilities.

And there’s the man who authored Dog Star Adventure for SoftSide‘s May, 1979, issue, Lance Micklus. Before doing so Lance had already written and sold: Concentration (an adaptation of a classic game show); Robot (a maze game); Mastermind I and II (board-game adaptations); Breakaway (a pinball game); Treasure Hunt (a mapping exercise in the Hunt the Wumpus tradition); Renumber (a programmer’s utility); KVP Extender (keyboard utilities); and Personal Finance and Advanced Personal Finance (financial software). Most of all he was known for having written Star Trek III.3, a port of a classic space strategy game that originated on HP Time-Shared BASIC; and a suite of terminal emulation software that allowed TRS-80s to communicate with larger institutional machines and with each other via modem. Quite a portfolio, especially considering that Lance was not a seasoned programmer when he came to the TRS-80, having spent his career working as an electrical engineer in television and radio.

The TRS-80 was perhaps the ideal platform for fostering such Leonardos. Since its graphics capabilities were one step above nonexistent, art assets weren’t exactly a big concern. And then of course its sound capabilities were completely nonexistent, so strike that off the list. Combine this with the fact that 16 K of RAM places a sharp limit on possibilities even for the most ambitious, and virtually any program that was conceivable to implement on the TRS-80 at all was doable — and doable relatively quickly — by a single skilled programmer. There’s something kind of beautiful about that.

Another nice facet of these more innocent programming times was a blissful unawareness of intellectual property rights. Certainly the many adapters of copyrighted board games, not to mention that hugely popular Star Trek game, hadn’t signed contracts with the owners of their respective properties. Dog Star Adventure was “inspired” by the middle act of Star Wars, when the crew of the Millennium Falcon is trapped aboard the Death Star and must rescue Princess Leia and escape. It seems somebody got just a bit nervous this time, however, so the Death Star became the Dog Star, Princess Leia became Princess Leya, Darth Vader became General Doom… you get the picture.

As soon as you start the game the debt it owes to Scott Adams is obvious. Here we see the bridge function that Adams’s early games served in action; Dog Star Adventure was inspired by Adams’s work, having been written by someone without exposure to Adams’s own inspiration of the original Adventure. (UPDATE: Um, not quite. See my brief interview with Lance for more on Dog Star’s influences.) Note the “Obvious Exits” convention, and the shift from second-person to first-person narration that Adams initiated with Adventureland:

The game is somewhat easier than Adventureland, with fewer howlingly unfair puzzles, but it still has its dodgy moments, such as the storage area filled with “all kinds of stuff.”

Yes, you need some of that stuff; and yes, you have to guess what is there and what the game wants you to call it. I can’t quite decide whether I like this or hate it; there is a certain element of cleverness to the “puzzle” (imagine my satisfaction when I entered GET BLASTER and it worked).

There are also packs of stormtroopers wandering the complex. Fortunately, you can use the aforementioned blaster to take them out.

Unfortunately (but inevitably), your blaster has a limited amount of ammunition, and you can only GET AMMUNITION once in the storage area. So, you’ll be seeing this quite a lot:

Superficially, your goal in Dog Star Adventure is the same that it was in Adventureland: gather a collection of treasures into a certain location (in this case, the cargo hold of your spaceship). Clearly Mr. Micklus didn’t get the memo about the Sexual Revolution, because even the Princess herself is implemented as just another takeable treasure.

Look a little deeper, though, and you’ll find there’s something going on here that is very interesting. Instead of just collecting for hoarding’s sake, all of these treasures (presumably including the Princess) are actually good for something in the context of the plot. You’re collecting fuel for your spaceship; the Princess’s necklace, with a hidden computer chip that encodes “the location and strength of her Freedom Fighting Force”; General Doom’s battle plans, which you have recorded onto a TRS-80 cassette tape (maybe you should have made a few backups?). Nor does the game end immediately when you have collected all the treasures; you must still get the space station’s hanger doors opened somehow and launch your ship. It’s not exactly compelling drama, but there’s the skeleton of a real plot arc here, climaxing in triumph for the Rebel… er, for the Forces of Freedom.

In addition to being available on tape from The TRS-80 Software Exchange for the low, low price of $9.95, the complete Dogstar Adventure was also published as a BASIC listing in that May, 1979, issue of SoftSide for the budget-conscious (or the masochistic). One of the things about this era that feels bizarre today even to those of us who were there is how much software was purchased in this excruciatingly non-user-friendly form well into the 1980s. Not only were program listings a staple of the magazines, but bookstore shelves were full of books of them. When we complain about the illogical puzzles and guess-the-verb issues that plague virtually all of these early games, we should remember that it was possible for anyone with modicum of programming knowledge to find answers for herself just using the BASIC LIST command. When Dog Star‘s parser started to frustrate, for example, I hunted down these lines:

30650 VB$(1)="GO":VB$(2)="GET":VB$(3)="LOOK"
30700 VB$(4)="INVEN":VB$(5)="SCORE":VB$(6)="DROP"
30750 VB$(7)="HELP":VB$(8)="SAVE":VB$(9)="LOAD":VB$(10)="QUIT"
30800 VB$(11)="PRESS":VB$(12)="SHOOT":VB$(13)="SAY"
30850 VB$(14)="READ":VB$(15)="EAT":VB$(16)="CSAVE"
30900 VB$(17)="SHOW":VB$(18)="OPEN":VB$(19)="FEED"
30950 VB$(20)="HIT":VB$(21)="KILL"

Right there are all 21 verbs understood by the game. I would submit that source-diving was not only unpreventable but also anticipated, even relied upon, by authors. In this light some of their design choices are perhaps not quite so cruel and bizarre as they initially seem.

As it happens, I got a little bit too well reacquainted with the tribulations of the BASIC transcriber when I played Dogstar in preparation for this post. In one section of the game there’s a security robot who blocks you from escaping the jail area with Princess Leya. This robot likes McDonald’s hamburgers (in another era I would suspect a marketing deal, but as it is I’ll just have to chalk it up to really bad taste in burgers). Luckily there just happens to be a hamburger lying in the crew’s lounge. Thanks to my BASIC source-diving, I thought I had divined the correct syntax to use to feed it to the robot, but the game obstinately refused to accept it. It turns out that the version of the game I was using had a tiny typo, in this line:

7350 X=22:GOSUB21450IFY<>-1PRINTM6$:GOTO2125

It should have read like this:

7350 X=22:GOSUB21450:IFY<>-1PRINTM6$:GOTO2125

That’s the kind of damage that missing a single colon can do when typing in hundreds of lines of BASIC code by hand. Once corrected I could feed the hungry robot at last.

And yes, the original listing is all crammed together like that. The TRS-80’s BASIC interpreter doesn’t absolutely require spaces to separate the elements of each statement, and spaces use memory — so off they go, along with other niceties such as comments. Readable Dog Star Adventure is not.

Which makes the important role it played rather surprising. Remember all those hobbyists interested in creating their own text adventures? Well, as a competently put-together game conveniently provided to them in print (printers were still a rarity in these days), Dog Star gave them a model to follow in doing just that. (While Scott Adams’s adventures were also coded in BASIC, none was printed in a magazine until 1980, and their interpreter/data-file design made them more difficult to deconstruct than Dog Star‘s admittedly less flexible all-in-one approach.) Lance Micklus himself became increasingly absorbed with his communication products, forming a company of his own later in 1979 to market them, and never coded another text adventure. And yet his fingerprints are all over early text-adventure history, as countless bedroom coders built their own designs from the skeleton he had provided. That, even more so than its hints of actual plotting, is the biggest historical legacy of Dog Star Adventure.

Next time we’ll drop in on Scott Adams again, who like Lance Micklus had a very busy 1979. In the meantime, if you’d like to try Dog Star Adventure I won’t make you type it in from scratch. Here’s a saved state for the MESS TRS-80 Level 2 emulator — and yes, the hamburger-eating robot works correctly in this version.

A Few Questions for Lance Micklus
July 1, 2011

I recently was able to pass along a few questions to Lance Micklus, author of Dog Star Adventure, and I thought some of you might find his replies interesting.

Jimmy: Scott Adams mentioned in a couple of places that you convinced him he should recode his adventure engine using assembly language rather than BASIC. Do you happen to remember how this transpired?

Lance: I don’t recall talking with Scott about this but it was good advice. BASIC would have made these programs very portable – meaning they could easily be ported over from one system to another. But assembly language gave these programs speed and efficiency – and a better overall experience.

Jimmy: Anything at all you can tell me about the creation of Dog Star Adventure would be hugely helpful. As one of the first text adventures to appear after Scott Adams showed it was possible on the TRS-80 and the very first to have its source published in a magazine, Dog Star is quite historically significant, you see. As such, I just played through it yesterday, and I’m just starting to write a little piece about it for my blog.

Lance: In the mid 1970s I worked for Vermont’s public television station as a studio engineer. I also did some computer programming for our station. Since our station was part of the University of Vermont, we used their computers when we needed to. One of those computers had the original text adventure game installed on it. I believe this game was known as Get Lamp [actually, Adventure, of course] and that it was written in Fortran around 1972 [make that 1976 for Crowther’s original experiment, 1977 for the completed game]. It was very popular with the students. I began to play it when I had time, although I never really got into the game too deep.

Eventually, when the University upgraded their computer systems, we lost access to Get Lamp. It was about this time that I got my first personal computer – the TRS-80. I began writing programs to replace the ones I once played on the University of Vermont computers. Dog Star was my attempt to replace Get Lamp.

The story line for Dog Star was influenced by Star Wars. My story takes place on something similar to the Death Star. Star Wars had a Princess Leia. In Dog Star there was a Princess Leya.

One of the influences from Get Lamp that I carried over to Dog Star was the use of a common story telling device known as “the ticking bomb.” In Get Lamp the batteries in the flashlight go dead after a certain amount of game play. After that happens it is impossible to complete the adventure. In Dog Star it was a cheeseburger that got cold.

One of the techniques I used to write Dog Star was to give objects properties. There were actions and there were objects to perform actions on. Eating a cheeseburger was one action that caused something to happen – there was no more cheeseburger after you ate it. Talking to the cheeseburger was another possibility but it didn’t do anything.

Jimmy: This is even more open-ended, but: I wonder if you could talk a bit about what led you to buy a microcomputer at such an early date, and (especially) how you immediately started cranking out such a huge quantity of software. I understand from your web page that you worked in radio and television prior to the TRS-80. What kind of background (if any) did you have with computers?

Lance: I first became interested in computers in 1953 when I was 8 years old. One of my favorite TV programs was Superman starring George Reeves. One of the episodes from season 2 was called “The Machine That Could Plot Crimes.” It was about a machine named Mr. Kelso that was tricked by a bad guy to plot perfect bank robberies. I was fascinated by this machine. After watching the episode, I asked my mother if there really were such machines. When she told me that there were, I decided I had to have one.

Mr. Kelso's computer from "The Machine That Could Plot Crimes"

In 1964 I got a summer job as a computer operator at IBM in Poughkeepsie. This gave me an opportunity to toy around with a 1401 computer in assembly language. Although computers fascinated me – and still do – I also wanted to pursue a career in broadcasting. Much of my life has been spent going back and forth between these two careers.

Purchasing the TRS-80 in the fall of 1977 was the fulfillment of the dream I had when I was 8 years old – which was to have my own computer. I enjoyed writing computer programs and did it just for fun. I got into publishing my work as a way to share my creations.

As seems to keep happening on this blog, this interview puts the lie to a couple of assertions I made in my previous post. Namely, Lance did have some exposure to the original Adventure, albeit apparently quite briefly given the very limited window of time between Adventure‘s widespread distribution in the spring of 1977 and the release of the TRS-80 that fall. Still, Dog Star is also markedly similar to Scott Adams’s early efforts, such that I can’t believe the similarity is coincidental. Also, Lance’s background with computers was a bit more extensive than I had described it. Ah, well, living and learning is part of what this blogging thing is all about, right?

Just for fun, here’s a picture of Lance from the glory days of the TRS-80:

And here’s him and his lovely wife Dianne today:

These days Lance is hoping to produce a Christian-themed movie based on the legend of Santa Claus. He’s a very, very nice man.

Next time I really will get back to Scott Adams, and talk about (among other things) that switch to assembly language I asked Lance about.

A Busy 1979
July 5, 2011

To say Scott Adams had a productive 1979 doesn’t begin to tell the half of it. For starters, he released a rather staggering six complete new games: Mission Impossible, Voodoo Castle, The Count, Strange Odyssey, Mystery Fun House, and Pyramid of Doom. Of these, four were the sole work of Adams himself.

Voodo Castle was credited to Adams’s then-wife, Alexis. Still, the real situation there is muddled, as Adams has tended to downplay her contribution in recent interviews, saying that she was responsible only for the broadest strokes, leaving him to do most of the writing and all of the programming. What with the passage of years and the difficult feelings that accompany any divorce, it’s probably not possible to know anymore whether Alexis Adams deserves to be credited as the first female adventure-game designer, beating Roberta Williams to the punch by more than a year.

More definite is the contribution of Alvin Files to Pyramid of Doom. Working independently, with no access to source code or design documents, Files reverse-engineered Adams’s adventure-game engine, created a game of his own using it, and sent the result to Adams himself, who tweaked it a bit and released it as Adventure #8, which he acknowledges to be “90 percent” Files’s original work. Pyramid of Doom was released around October of 1979, but an early sign of the budding relationship can be seen in that summer’s The Count, which is “dedicated to Alvin Files.”

In sorting out this chronology via magazines and other primary-source documents, I was quite surprised to realize that fully two-thirds of what has come to be regarded (somewhat arbitrarily) as the canonical dozen Scott Adams adventures were created before Adams’s company, Adventure International, was even founded. Said founding occurred just before the end of the year, by which time Adams was already involved in another important step: porting his adventure engine to run on other microcomputer platforms. The logical first target for these efforts was the Apple II, the second most popular machine in 1979, but within a few years the explosion of incompatible machines and Adams’s dedication to supporting as many of them as possible would bring the games to at least a dozen different platforms. While 1979 wasn’t yet the year that adventure games broke really big, it was the year that Adams laid the groundwork for their doing so, for the changing of the calendar left him poised with a new company, a portable adventure-game engine, and a nice catalog of already extant games in a wide variety of genres. He had even created a stripped-down “sampler” version of Adventureland for those looking to test these new waters.

Even on the good old TRS-80 Adams made major technical improvements. At the apparent urging of Lance Micklus, he reimplemented his interpreter using assembly language rather than BASIC between the release of Mission Impossible in the spring of 1979 and Voodoo Castle and The Count that summer, bringing enormous speed improvements. He also implemented a new display system that would become something of a trademark, with the current room description and contents always displayed in a separate, non-scrolling “window” in the upper half of the screen. Given the TRS-80’s 64-character by 16-line display and the attendant tendency for everything of interest to scroll away in no time, this amounted to a major convenience. The new interpreter even supported lower-case output, although prose style, grammar, and even spelling remained all too obviously not a big priority. With these improvements the new system, which was quickly retrofitted back into the first three games as well, made TRS-80 adventuring a much more pleasant experience.

But what of the content of the games themselves? Well, both their limited engine and the torrid pace at which Adams cranked them out acted as a necessary limit on their scope of possibility, but there are some new developments worth talking about. Chief among them is the element of time. Both the original Adventure and Adventureland had of course required close attention to time management thanks to their expiring light sources, but Mission: Impossible introduced the element in a more plot-centric way, in the form of a ticking time-bomb that threatened to destroy a nuclear power plant. And two games on from that we have The Count, a game that is about as conceptually ambitious as Adams would ever get and a significant step forward for the text adventure as a storytelling medium. I’ll look at The Count, by far the most interesting of these six efforts, in some detail next time.

The Count
July 7, 2011

The Count opens with a title screen that would become iconic and almost bizarrely long-lived, finding its way not only to all of the other games in the classic Scott Adams series on the TRS-80 but to all of those other platforms on which the line would eventually arrive as well. Even when the games were ported to the illustrated SAGA system, this screen was little changed.

Looking at it, a few things are immediately striking. First there is Adams’s indelible, lackadaisically enthusiastic writing style that stamps all of his games better than could their maker’s signature. As near as I can tell, the interpreter is called simply ADVENTURE and is at version 8.2 already (!), while the game of The Count itself (“Adventure Number 5”) is at version 1.15. The plea which concludes the message shows that software piracy was already a significant problem in 1979, and not just a bugaboo of Bill Gates. As time went on, it would of course only become a bigger issue, as pirates formed sophisticated distribution networks and a whole fascinating if amoral subculture of their own; I’ll talk more about that when we get there. Still, Adams was himself not above stretching the truth a bit to get his point across; he obviously didn’t spend “over a year” developing The Count when he released five other games in 1979 alone. (Or perhaps he was referring to the system of ADVENTURE as a whole?)

But, you might be asking, why does the text look so funny? Well, you may remember my saying that the standard TRS-80 did not come equipped with support for lower-case letters. In a sense, that’s only partially true. The character ROM, which contained the glyphs for all displayable characters, did have glyphs for all lower-case as well as upper-case letters; presumably it was, like most components of the TRS-80, an off-the-shelf part that was easier to leave alone than it would have been to modify to remove the extra glyphs. What the TRS-80 really lacked was a way to input lower-case. The ever-inventive aftermarket soon addressed this with various modification kits, one of which Adams had obviously acquired by early 1979. Even with the kit, though, the TRS-80’s display, having been designed with only upper-case in mind, still lacked the concept of descenders. Thus letters like “y,” “p,” and “g” are perched on the line rather than dangling below, creating the decidedly odd appearance you see in the image above. Like everything that doesn’t kill you, you get used to it.

But now let me talk about The Count specifically, and what makes it such a unique and interesting entry in the Adams canon. While Mission Impossible had introduced the use of time in the direct service of plot in the form of a (literally) ticking time-bomb, The Count goes much, much further. As it begins, we wake up in a bedroom of a house that is being haunted by Dracula himself. We have been placed there by the frightened inhabitants of the local village, and given strict instructions to either kill Dracula or die — or, presumably, become a vampire ourselves — in the process. (Of course, thanks to the typically sparse text, lack of supporting documentation, and old-school design we infer all this only when we attempt to leave the house and get killed by an angry mob, all of which leaves one to wonder whether Dracula or the villagers are the more evil… but we’ll let all that go.) The plot unfolds over the next three — or, just possibly, four — afternoons and evenings, during which we must maneuver everything into position to finally administer the obligatory stake through the heart that ends Dracula’s reign.

Not only does time pass over the course of these days, with afternoon trailing into night (with the expected effect on the general lighting situation), but there are actual plot-related events that happen in the storyworld, in the form of a pair of deliveries on the first and second afternoon.

As always, we don’t want to go too far here; this still isn’t anything close to a serious, nuanced story, as the game remains firmly entrenched in the usual jokey Scott Adams style.

What we do have here, though, is a storyworld that is at least in some senses more dynamic than anything we’ve seen before; while Adventure could boast the independently moving dwarfs and pirate that were surprisingly sophisticated in their way, its world was otherwise static prior to the triggering of the endgame, and lacked any sense of time other than the expiring lantern. Notably, The Count adds a WAIT verb, a command that would have been superfluous in earlier games, as the player must plan her actions around the time of day and those all-important package deliveries.

In practice, the game plays out like a whole new type of systemic meta-puzzle, as the player maps out how events unfold and how everything works — dying countless times in the process — to come up with a final plan for victory. The Count introduces nothing less than a whole new paradigm of play for the text adventure, one focused not on geographic exploration (the map is very small and manageable for the era) but on dynamic, systemic thinking that feels much closer to engaging with a narrative. Its system is even sophisticated enough to support quite a number of different paths to victory; virtually every walkthrough for the game I was able to find has its own unique approach.

Still, at times the boundaries between the system of the storyworld and the system of the program are hazy, such that one is often left feeling one is playing the program rather than playing the story. For instance, one travels between floors using a dumbwaiter (the lack of a staircase is one of those sins against mimesis we can forgive in such an early, primitive game). If one passes out and is put to bed (presumably by Dracula) for the night while on another floor than the one containing the bedroom, the dumbwaiter is left on the former floor, locking one out of victory. This of course makes no sense in the storyworld — whoever heard of a dumbwaiter that can only be raised or lowered by someone riding on it? — but is a limitation of the program. Indeed, much about solving the game can be more tedious than fun; the learning-by-death syndrome is one that even Infocom would never entirely solve in its similarly dynamic mysteries. Frustrations like these make The Count perhaps less entertaining as a game than it is interesting as technology and as a concept; nor does its ending exactly pull out all the stops.

Adams himself didn’t do much to build on these concepts, largely retreating to treasure hunts and similarly static designs in subsequent games, leaving this approach to be taken up by Infocom three years later with the groundbreaking Deadline. But again, we’re getting ahead of ourselves…

If you’d like to play The Count in its original form yourself, here is a CMD file you can load into the MESS emulator using “Device –> Quickload” from the emulator menu.

Two Adventuring Cultures
July 12, 2011

By the time that Adventureland had its first anniversary, adventure games on the TRS-80 were already amongst the platform’s most popular software offerings. And now, thanks to Scott Adams’s portable adventure engine and the fact that virtually all non-Adams adventures were still written in relatively standard BASIC, they had begun to pop up on other microcomputer platforms as well. A new art form was on the scene. As early as its June, 1979, issue, SoftSide published an “Engagement Announcement” between the TRS-80 and “Fantasy”:

The staff of SoftSide is eagerly anticipating the birth of a new art form as a result of this match. We feel that one of the most creative art forms of the future will be the participation novel, in which you assume the role of a character and alter the direction of the story by your own actions, instead of simply reading what the original author conceived and wrote.

Right now, creative people who’ve been writing elaborate simulation games are working on computer adaptations. The progress they’re making is exciting, with greater things to come! In our December issue, we presented Santa Paravia en Fiumaccio, breaking new ground in simulations on computer. [Written by Reverend George Blank, Paravia was an adaptation / expansion of Hamurabi, a resource management strategy game dating back to 1968 and eventually ported to BASIC by David Ahl, founder of Creative Computing magazine. As the first computer game to explicitly ask the player to play a role in a storyworld of sorts, Hamurabi is of great historical and theoretical significance in its own right.] In May we presented you with Dog Star, bringing us one step closer to the electronic novel. We foresee the time when elaborate simulations of high literary and artistic quality will captivate the leisure hours the way television does today, in much the same manner that television replaced radio drama, and radio drama led to a decline in reading for pleasure.

In March, SoftSide was contacted by the publisher of The Dungeoneer and Judges Guild Journal, two magazines specializing in the simulation game Dungeons and Dragons. In a copy of The Dungeoneer we were surprised to find a list of sixty-one other magazines also specializing in fantasy, war and simulation games. We also discovered that many of these people are starting to use the TRS-80. [I’ll be exploring this linkage between the nascent computer-game industry and the rapidly expanding world of tabletop role-playing games very soon.] Once the creative work they’re doing is suitably married to the computer, the electronic novel will be born! We’re certain the day is not far off, and we intend to be part of it!

Shortly afterward, SoftSide began using the rather awkward term “compunovels” to refer to these new works, the first of many attempts by writers, commentators, and players to get away from the somewhat limiting labels of “adventure games” or (a bit further on) “text adventures” to something reflective of more literary aspirations.

Of course, the idea of the “compunovel” was more aspirational than it was reflective of the reality of 1979, when the Scott Adams games with their childlike diction, “weirdly errant grammar” (in the words of Graham Nelson), and merest stubs of plots were the class of the adventuring field. Indeed, for many contemporaries these claims for literary grandeur must have seemed downright delusional given the reality of the time. It’s to the great credit of the writers at SoftSide that they could see the potential of the new form once freed of the technical constraints of 16 K of memory and cassette-based storage, and of the artistic constraints imposed by programmers attempting to get by as writers.

Still, there was another culture that was largely free of the first if not the second set of constraints: the institutional hacking culture that had birthed adventure games in the first place. By 1979 the big machines hosted quite a variety of them: Zork at MIT; Stuga, the first adventure game created outside of the United States and the first in a language other than English, at Stockholm Computer Central; Acheton at Cambridge University in England; Mystery Mansion at (of all places) the Naval Warfare Engineering Station in Keyport, Washington. Meanwhile others, free of the commercial considerations that were already coming to dominate the microcomputer software market, set about improving and expanding upon the original Crowther and Woods Adventure, creating a dizzying number of variations that have come to be referred to by their maximum possible score. The original game, which offered 350 potential points, is sometimes called Adventure 350, while its successors include Adventure 365, Adventure 550, and many others, finally many years on culminating in the inevitable Adventure 1000. Even Woods himself created an expanded 430-point version before leaving adventure creation behind for good.

The most immediately striking characteristic of all of these games today is their sheer size; they still remain some of the largest text adventures ever constructed in breadth if not depth, boasting hundreds of rooms each. Their scale was a byproduct of the culture that created them. In the hacker ethic, no program was ever considered truly finished; there was always room for more tweaking, more features, just more. Since these games were not commercial endeavors, there was no necessity to declare them done and ship them out the door at any given point. They therefore often remained in a sort of playable development stage for literally years, growing in fits and starts as the interest levels of various contributors waxed and waned. (Another thing which distinguished these games from their microcomputer counterparts, and indeed from most IF of today, is that they tended to be team efforts.) Zork, for instance, first appeared on MIT’s computer system in May of 1977, hot on the heels of the Adventure phenomenon, but was not finished until February of 1979. Even at that point, the game was not really done in any thematic or design sense. Its creators had simply managed to fill up even the cavernous one megabyte of memory on their DEC machine, and thus were physically unable to continue to build yet more new rooms.

If you’re thinking that such a development model might ultimately be as limiting to narrative possibilities as were the absurd hardware limitations of early home computers, well, you’re pretty much right. The team that created Zork, for instance, contained some genuinely talented writers, perhaps more so than anywhere else in the adventuring world of 1979. Yet their best efforts were continually undone by the “too many cooks in the kitchen” syndrome, with descriptions of real imagination and elegance juxtaposed with others of a Scott Adams-like terseness. And the design itself is similarly sprawling and unfocused, with great ideas layered upon less great ones in seemingly random fashion. Zork and other, possibly even larger games like Acheton are vast and chaotic almost to the point of incomprehensibility. In this light the technical constraints of microcomputers, which forced authors to create games that were thought-through, structured designs rather than random sprawls, don’t look quite so bad. Or, to put it another way: bigger is not always better. It’s telling to note that none of these games had a narrative arc anywhere near as tight and coherent as that of The Count.

Still, TRS-80 owners working their way through the constrained environments of Adventureland, Dog Star Adventure, and The Count might be forgiven for casting some jealous glances in the direction of all those rooms, all those objects, all that space for text. It was therefore kind of a big deal when the daddy of all those institutional extravaganzas, Adventure itself, first came home. If Adventure could be made to run on a TRS-80, it seemed reasonable to think that other larger, more ambitious games should soon be possible on microcomputers as well — which was of course exactly what ended up happening. Indeed, within a few years adventure-game development on the big machines would pretty much dry up entirely.

The name of the company that first brought Adventure home via the TRS-80 might just surprise you. More on that, and them, next time.

Microsoft Adventure
July 14, 2011

There’s a good chance that you’ve received a forwarded email at least once or twice during the past ten years or so with the photograph above and a snarky caption such as, “Would you have invested?” The picture shows eleven of the thirteen Microsoft employees as of December 7, 1978, just before the company decamped from its first home in Albuquerque, New Mexico (initially chosen because it was the home of Microsoft’s first customer, the now increasingly irrelevant MITS) for the big time in Seattle. The twelve-year-old at the bottom left is of course Bill Gates himself… and, believe it or not, he’s actually already 23 there.

Ah, what can I say about Bill? I suppose you don’t become a multi-billionaire without leaving some bruised egos in your wake, but old Bill has always had a special knack for pissing people off and generally coming off like the computer industry’s own version of Darth Vader. In the abstract, I’m not sure that he was really so much more evil than most of his peers. Even by the time this photo was taken, the digital utopianism of the People’s Computer Company and Creative Computing was beginning to take a beating from a whole lot of would-be titans of industry looking to get a piece of the new microcomputer action — people like Commodore head Jack Tramiel, who announced that “business is war” and then wondered why all of his business partners and employees were so surprised when he lied to them and betrayed them; or like Steve Jobs, who even before co-founding Apple swindled his best friend out of a $5000 bonus he had earned doing his job for him, disingenuously prattling on about hippie togetherness and Eastern philosophy all the while. Perhaps the closest to moral in this lot was the management of Tandy, who were so unimaginative and so out of touch with their competitors that they couldn’t really be bothered to actively try to wrong them.

The big difference with Gates was that he was so damned good at being evil. While everyone else wound up to one degree or another hoisted from their own petards for their misdeeds, Gates just prospered. He wasn’t so much immoral as ammoral. Unlike Tramiel, who seemed to positively revel in his evil, or Jobs, who desperately wanted to be seen as the good guy whatever dirty tricks he was pulling behind the scenes, Gates seemed utterly indifferent to his image and utterly disinterested in the niceties of right and wrong. On a personal level, he seems to have inspired something between ambivalence and out-and-out dislike in everyone who wasn’t directly depending on him for their salary (or, perhaps, the latter group just couldn’t speak up about it). It wasn’t just that his personal hygiene left as much to be desired as his interpersonal skills. Nor was it just that he displayed all the arrogance of both a brilliant programmer and the Harvard scion of a prosperous family; that was to be expected, considering that he was both of these things. No, it was the sheer magnitude of Gates’s need to win and to dominate those around him that made him downright disturbing to be around for so many people. If Gates couldn’t win at something fairly, one never doubted that he would cheat. Hell, if he could win at something fairly but it was just easier to cheat, he’d probably choose the latter course there as well. But, here’s the thing: Gates always cheated smart. If ethics didn’t mean much to him, he was very aware of legalities, and always careful to make sure that even at his shadiest he stayed on the right side of that line. (Of course, he became increasingly less good at that in the 1990s, but that’s a story for another time…) Remember the blinkered MIT nerds that Joseph Weizenbaum railed against in Computers and Human Reason? Well, the young Gates fit that stereotype perfectly, with with an added heaping measure of cold-blooded ruthlessness. His wasn’t a personality likely to win a lot of friends. As an investment opportunity, however…

The story of Microsoft Adventure provides a good early illustration of both the very real technical and marketing acumen of Gates’s company and its genius for ignoring ethical considerations while still staying on the right side of the law. It provides an early example of what was already becoming the company’s modus operandi, one guaranteed to piss off idealistic hackers as much as it would delight its financial backers. And, not incidentally, it also represents a very important moment in the continuing evolution of adventure games.

In 1979, fully two years before Gates’s genius stroke in partnering with IBM on the original IBM PC, Microsoft was already a very big fish in the still relatively small pond that was the microcomputer industry of the era, having built a strong business upon the solid foundation of that initial Altair BASIC. In fact, Microsoft was simply the company to go to for a microcomputer BASIC implementation; it provided not only the TRS-80 Level 2 BASIC, but also the BASICs in the Commodore PET and the just-released Apple II Plus. It had also already expanded into other high-level programming languages, producing the first implementations of FORTRAN and COBOL to appear on microcomputers. Microsoft Adventure was part of a new initiative for 1979, the Microsoft Consumer Products Division, which aimed to market games and less esoteric applications to everyday consumers. The division as a whole was arguably somewhat ahead of its time, and would not be a rousing success in the long term. (Microsoft gave up on it within a few years to focus almost exclusively on technical and business products, and, the long-lived oddity Flight Simulator aside, would not begin marketing games and applications directly to home users once again until the 1990s.) For now, though, Consumer Products was big at Microsoft. With adventure games becoming so big on the TRS-80, when an employee named Gordon Letwin said he could port the original Crowther and Woods Adventure, something of a semi-legendary holy grail to microcomputer adventurers, onto the little machine, the go-ahead wasn’t long in coming.

Gordon Letwin is the bearded, black-haired fellow at the far right of the second row in the picture above. Born in 1952 and thus three years older than Bill Gates himself, his character and background is not too far removed from that of other hackers we’ve already met on this blog. A withdrawn, almost disturbingly nonverbal personality, Letwin read non-fiction books by the dozen throughout his childhood and teen years. Upon entering Purdue University as a physics major (the same major Will Crowther had chosen a decade earlier), Letwin found his real calling in the university’s computer center. After university, he got a job with Heath Company, who were well known among electronics hobbyists of the time for their “Heathkits,” do-it-yourself kits that let hobbyists build test equipment, amplifiers, radios, even televisions. In 1977 the line was expanded to include a computer, the H8, for which Letwin designed a simple operating system called H-DOS. He also designed a BASIC of his own, but a young and aggressive Gates, much to Letwin’s chagrin, dropped in on Heath while making the rounds of microcomputer manufacturers to try to convince them to buy Microsoft’s version. Letwin did something interesting, something that few others would ever do: he stood up to Gates. In Gates’s own words:

“There are different ways to do this stuff. His had some advantages which he was pointing out to me. We ended up in this argument between two technical guys. There were about 15 people in the room and no one else could follow along. We’re talking all in terms of data structure, single representations, double scan, stuff like that… Like if you typed a bad line, his would immediately check the syntax, and mine wouldn’t. Which is one of the negative points of our design. Anyway, he was being very sarcastic about that, telling me how dumb that was.”

Deciding perhaps that the adage that no one ever got fired for buying Microsoft was true even in 1977, Heath’s management elected to replace Letwin’s in-house design with Microsoft’s BASIC. This left them with one very angry Letwin. Gates, who whatever his other failings knew talent when he saw it, poached him for Microsoft about nine months later, not too terribly long before the above photograph was taken.

Although Letwin and his wife lived very modestly even years after Microsoft had made them wealthy, he more so than most hackers always knew the value of a buck, and always wanted to get what was coming to him. A 1988 Seattle Times profile alleges that he was a major impetus behind the decision of Gates and Paul Allen into transform Microsoft from a partnership to a corporation in 1981, and to grant him and other early employees like him the shares that would make them very rich indeed by the end of the decade. I mention this here because it may explain something odd about Microsoft Adventure: it was published by Microsoft, but allegedly developed by an entity called Softwin Associates, a company that apparently consisted of only Letwin himself. It seems that Letwin developed Adventure as something of a moonlighting project, then licensed it back to his employer. Why do it that way? Well, doing so gave Letwin the ability to collect royalties on sales as an outside contractor, above and beyond his regular employee salary. That the very finances-focused Gates let him get away with such a scheme probably says a lot about his perceived value to the company.

As Microsoft claimed in the instruction manual, “With Microsoft Adventure, you have the complete version of the original Adventure. Nothing has been left out of the original DEC version.” That stands as quite a neat trick; remember that Scott Adams, himself an experienced programmer, had not even tried to do a direct port but had instead developed Adventureland as its own, much smaller game. How did Letwin manage it?

He first of all took advantage of Radio Shack’s expansion interface, which allowed the user both to expand memory beyond 16 K and to replace cassette-based storage with floppy disks. This was a bold choice in its way, dramatically limiting the potential buyers of Adventure; in its September, 1979, issue, SoftSide reported that “only a few” of its readers had yet bought Radio Shack’s $500 disk drive. Yet Adventure would have been impossible without it.

The benefits of expanded memory were obvious in allowing longer and more complex programs, but those of the floppy disk were both obvious and more subtle. On the obvious level, the floppy was superior to the cassette in every way, allowing users to store much more data on a single piece of media and to save and retrieve it many times faster and with many times the reliability. But another attribute of the floppy would be key to the implementation of major games like Adventure given the still tiny amount of memory 32 K actually is. Unlike the cassette, the floppy was a random-access storage device, meaning the TRS-80 could be programmed to load into memory chunks of data from all over the disk as a program ran. By comparison, reading from the cassette required that the user manually position the tape in the correct position using the player’s counter, then press play… and then, of course, wait, for up to 20 minutes just to load one of Scott Adams’s simple adventures. With a disk drive, then, Letwin could leave all of that text that was stored in an external file even in Crowther and Woods’s original on the disk, loading in only the bit and pieces that he needed as they were needed. He needed only pack the core code of the game itself into his 32 K — not that that was a trivial task in itself, requiring as it did that Letwin port the original FORTRAN code into Z80 assembly language while optimizing everywhere for speed and size. Letwin’s pioneering use of the disk drive as a sort of auxilliary memory would soon enough be everywhere, refined to something of an art by companies like Infocom. Countless classic games would have been simply impossible without it.

The arrival of disk drives also brought with them another, less welcome innovation: copy protection. Every computer has a standard format in which it arranges data on its disks. To simplify rather extremely, locations on the disk are broken down into track and sector numbers, with a master directory stored in some standard location that records all of the files stored on the disk and their location by track and sector; this allows the computer to locate and retrieve files as they are requested. Most early disk copying programs assumed that the disk being copied would be laid out in this standard format, and would simply attempt to copy each file they found in the master directory over to the new disk one by one. It was, however, relatively easy for a program like Adventure to replace the standard disk format with one of its own devising — one that it knew how to read, but which would completely flummox another program expecting a standard format. By later standards, Adventure‘s copy protection was relatively simple, just rearranging the numbering scheme used to identify the different sectors on the disk. It was also relatively kind in allowing at least those with two disk drives to make a single backup copy by entering a special command within the program itself. Later protection schemes would get much more sophisticated, and much less kind.

Microsoft Adventure also points toward the future in its packaging. It shipped in a real box with real, professionally produced artwork and a multi-page, glossy manual written by Dottie Hall. Contrast this with the packaging of the early Scott Adams games, constructed from a plastic sandwich bag, a business card, and a baby formula liner. In 1979, Microsoft was one of the few software companies with the resources to give its products a professional presentation. As the games industry grew more professional and profitable, however, packaging would become a huge part of the whole experience of adventuring, reaching glorious (some might say absurd) heights of lurid artwork, lengthy manuals, included novellas or even novels, elaborate maps (sometimes from cloth or parchment), and evocative physical props (“feelies”).

Microsoft Adventure also started another, related trend that became almost as prevalent: its artwork has almost nothing to do with the actual game it represents.

I certainly never imagined the jokey response to “KILL DRAGON” (“CONGRATULATIONS! YOU HAVE JUST VANQUISHED A DRAGON WITH YOUR BARE HANDS!”) playing out quite like that. Although, I guess with sufficient imagination…

Having dwelt on the original DEC versions at length, there’s not really that much to say about the actual playing experience of the version of Adventure that Letwin developed. It is exactly what Microsoft claimed it to be, a slavishly faithful port of the original, minus only such PDP-centric niceties as “cave hours.” I suspect that most of the in-game text is literally the same as that on the PDP original, being the original’s external data file simply copied over to a TRS-80 floppy. Interestingly, Letwin does make an effort to ease some of the original’s more nonsensical puzzles. In the original, for instance, one could earn the “last lousy point” only by dropping the Spelunker Today magazine at Witt’s End, a completely unmotivated action; in Letwin’s version, reading the magazine (new renamed to LWPI for some reason; any readers have any ideas what this might reference?) now yields the vital clue that “ITS ADDRESSED TO WITTS END!” Even better, the richly described but previously useless “Breath-Taking View” now has a purpose of sorts, for Letwin adds a single line that helps out with another notorious puzzle: “WORDS OF FIRE, APPARENTLY HANGING IN AIR, SAY ‘PLOVER.'” What a guy!

Nudges like that aside, Letwin makes just one addition, the “Software Den.”

YOU ARE IN A STRANGE ROOM WHOSE ENTRANCE WAS HIDDEN BEHIND THE CURTAINS. THE FLOOR IS CARPETED, THE WALLS ARE RUBBER, THE ROOM IS STREWN WITH PAPERS, LISTINGS, BOOKS, AND HALF-EMPTY DR. PEPPER BOTTLES. THE DOOR IN THE SOUTH WALL IS ALMOST COVERED BY A LARGE COLOUR POSTER OF A NUDE CRAY-1 SUPERCOMPUTER.

A SIGN ON THE WALL SAYS, “SOFTWARE DEN.”

THE SOFTWARE WIZARD IS NOWHERE TO BE SEEN.

THERE ARE MANY COMPUTERS HERE, MICROS, MINIS, AND MAXIS.

Messing with any of the computers results in:

AS YOU REACH FOR THE ELECTRONIC GOODIES, AN ENRAGED BEARDED PROGRAMMER JUMPS OUT OF CONCEALMENT. “AHA!” HE CROWS, “I’VE FOUND THE SOB (THAT’S ‘SUBTRACT-ONE-AND-BRANCH’) THAT’S BEEN STEALING MY EQUIPMENT! HAVE YOU FORGOTTEN THAT MY WIZARDLY SPELLS HELP KEEP THIS CAVE TOGETHER? FIRST, I’LL REMOVE SOME OF THE TREASURES:

DESTROY (TREASURES);

THEN, I’LL REVOKE SOME MAGIC WORDS:

REVOKE (MAGICWORDS);

FINALLY, I’LL KICK YOU DEEP INTO THE MAZE!”

YOURLOC = DEEP.IN.MAZE;

YOU ARE IN A MAZE OF TWISTING LITTLE PASSAGES, ALL DIFFERENT.

Talk about your delusions of grandeur…

But now we come to the elephant in the room: the question of credit. At no place in the Microsoft Adventure program or its accompanying documentation do the names of Crowther and Woods appear. We are told only that “Adventure was originally written in FORTRAN for the DEC PDP-10 computer,” as if it were the result of a sort of software immaculate conception. Needless to say, Crowther and Woods were never contacted by Microsoft at all, and received no royalties whatsoever for a program that by all indications turned into quite a nice seller for the company; it was later ported to the Apple II, and was one of the programs IBM wanted available at day one for the launch of its new PC in 1981. Because Crowther and Woods, immersed in old-school hacker culture as they were, never even considered trying to assert ownership over their creation, Microsoft violated no laws in doing this. However, the ethics of cloning someone else’s game design and lifting all of their text literally verbatum, and then copy protecting it (the irony!) and selling it… well, I don’t think that calling it “ethically dubious” is going too far out on a limb. In his famous “Open Letter to Hobbyists” of 1976, Gates asserted the moral right of the creators of software to have control over their creations. How to reconcile that stance with Microsoft Adventure? Incidents of commercial co-option of free software like this one are what eventually led to the creation of licenses like the GPL, designed to make sure that free software stays free. If you’ve ever wondered why so many in the open-source communities are so obsessed with the vagaries of licenses, maybe stories like this one will give an idea.

Be that as it may, Gates now seems as dedicated to doing good in the world and giving away his money as he once was to crushing his business competition and amassing it, to which I give a big hooray. I’d say that saving a single child makes up for the dubious aspects of Microsoft Adventure many times over. Gordon Letwin, meanwhile, also stayed with Microsoft for many years, going on to head the ill-fated OS/2 project before retiring on all that stock in 1993. He now also devotes himself to charity, specifically to environmental causes. A second hooray there.

Ironically, Microsoft Adventure is such a perfect clone of the original that it is now the ideal choice of anyone who wants to experience said original in as authentic a form as possible without building a whole virtual PDP-10 of their own. I’ve made a TRS-80 disk image of it available here, which will stay up as long as Microsoft’s lawyers don’t come after me for pirating their stolen 32-year old software and talking bad about their “non-executive chairman,” but for an easier time of things you might want to hunt down the IBM PC version on an abandonware site. If you do go with the TRS-80, you’ll have to play it using the SDLTRS emulator rather than the MESS version, as, due to the on-disk copy protection mentioned earlier, the disk image has to be stored in the “DMK” format — a format that MESS unfortunately cannot read. Really sorry about that!

I’ll be looking at text adventures in 1980 — a very exciting year — soon. But next I want to make a little detour into some theory and then into another genre of story-oriented game.

Ludic Narrative née Storygame
July 20, 2011

I’m not done with this little stroll through history — in fact, I’m just getting started — but I want at this point to take a few posts to introduce some theoretical ideas that will be informing the history to come. I’ll try to make it as painless as possible… really, I will.

When I was a kid growing up in the 1980s, the broad category of “adventure games” as covered by folks like Scorpia in Computer Gaming World was generally taken to be composed of four distinct subtypes. There was of course first the form I’ve been focusing on in this blog so far, the text adventure (or, if you like, interactive fiction), which I trust needs no further definition. There was the computer role-playing game (CRPG), a less rigid, more emergent form which focused on strategy and tactics in sending the player forth to do battle with multitudes of monsters or, occasionally, mutant humans or space aliens. There was the point-and-click graphical adventure, which like the text adventure tended to be built around set-piece puzzles rather than simulational emergence, but which replaced descriptive text with pictures and the parser with a joystick or mouse. (This form should not be confused with text adventures which happened to feature pictures.) And finally there was the action adventure, which combined reflex-oriented jumping or fighting gameplay with puzzle-solving, exploration, and an overarching storyline or quest.

So, four quite disparate approaches, no? Given that disparity, I started asking myself a number of years ago just what prompted people to see such kinship among these forms, kinship they didn’t also see in, say, a strategy game like Archon or a pure action game like Frogger. Or, put another way: what was it about these forms that made them uniquely appealing to a columnist like Scorpia, or for that matter to a young nerd like me? Clearly it wasn’t a question of their fictional context; while dwarfs and dragons may have been disproportionately represented in the group of four, there were also plenty of non-fantasy examples — not to mention plenty of strategy and action games with fantasy themes that clearly did not fit in the group of four. The answer I came up with, which I’m sure will surprise no one, was that the distinguishing feature of these forms was that they all foregrounded story in a way that didn’t really happen in other forms of 1980s computer gaming. From there, I decided to try to codify the unique qualities of these games in a way that would be a bit more definite, not to mention applicable to other technologies and eras. In the end I came up with two approaches, actually, one a fairly rigid checklist and the other based more on abstracts.

But before I defined them, I first had to decide what I wanted to call the category of works in question. At first I simply went with storygames, but lately I’ve been leaning more toward ludic narratives. I favor the latter not because it sounds more academic and pretentious, although that it certainly does, but rather because I think the narrative component of these works is of equal or even greater important than the systems of rules — the “game” part — that underlie them. But I’ll get into that a bit more in my next post. For now, let’s just roll out the definitions, beginning with the rigid checklist approach.

So, then, to qualify as a ludic narrative a work must possess the following four attributes:

1. The work must be directly and obviously interactive. When I say “directly and obviously” here, I mean that if there is any real question the work probably fails this test. Joyce’s Ulysses and Nabakov’s Pale Fire, for instance, may have a certain sense of interactivity about them in that they demand a certain sort of engaged, motivated reading, but they still carry, at least outwardly, the form of conventional, linear novels, and thus fail this test.

2. A computational simulation — a “storyworld” — must enable the narrative. It should be noted that a computational simulation does not automatically mean a computerized simulation, as a human rather than a computer can administer the rules of the ludic narrative. This simulation can run at virtually any level of abstraction, but it must be there. Hypertext literature thus does not qualify as a form of ludic narrative, as no simulation exists “behind” the links one clicks in “playing” a hypertext.

3. The player must play the role of an individual in the storyworld, experiencing events through the eyes of and in the persona of that character. Some ludic narratives may allow the player to switch roles or even play several simultaneously, but she is always immersed in the storyworld rather than viewing it from an on-high, abstract perspective. Thus a game like Civilization, which is played at the macro level, does not qualify as a ludic narrative.

4. There must be a coherent story arc, and it must be possible to well and truly complete that story. A massively multiplayer online role-playing game like World of Warcraft thus does not qualify as a ludic narrative, as it has no endpoint, and is ultimately experienced as a series of anecdotes rather than a coherent story.

Having just disqualified several games in the definitions above, let’s quickly return yet again to our old friend Adventure for an example of a game that does qualify as a ludic narrative. It satisfies criteria #1 in that it is directly interactive, responding to player inputs through a textual parser. It satisfies criteria #2 in that a simplified simulation of the real world houses the action, allowing the player to pick things up, carry them around, and leave them in other places; to open and close doors; and even to interact (simplistically) with other characters who autonomously move about the storyworld with agendas of their own. It satisfies criteria #3 in that the player interacts and views the storyworld strictly through the persona of a character in that world, the nameless “adventurer.” And it satisfies criteria #4 in that Adventure has an extant, if simplistic almost to the point of transparency, story arc and goal. Its plot even has a climax in the form of the closing of the cave and the visit to the control room. That said, it’s also true that if Adventure comes close to failing to qualify as a ludic narrative anywhere, it is here. The Oregon Trail, for example, is actually a stronger example of the form in that its story arc is much more pronounced and was much more of a priority for its designer.

Actually, speaking of “stronger” or “weaker” examples of ludic narratives brings me to the other way of looking at the subject. When I first came up with the set of criteria above, I put it in my little backpack of theoretical constructs and continued on my way, smugly sure I had “solved” this little problem of ludic taxonomy. As time has passed, though, I’ve become more and more aware that rigid categorization is not always the best approach, that it may often be better to consider ludic narrative in a gradient (“more or less”) fashion rather than as an “either/or” proposition. In doing so I’m drawing a lot from the cognitive scientist George Lakoff. Consider, to use one of Lakoff’s examples, the concept of “bird,” not as it’s understood scientifically but as it’s thought of in everyday life. Lakoff writes that, while people recognize both robins and emus to be birds, the robin is in some sense also recognized as more “birdy”: it can fly while the emu cannot, it sings while the emu does not, etc. In Lakoff’s formulation, there is some central idea of absolute birdyness (it may be helpful to think of Plato’s ideas about the Good). The robin is closer to this central idea than the emu, but both are close enough that if queried most people would recognize them both to be birds. I believe we can when it suits our purposes consider (potential) ludic narratives in the same way, in which case The Oregon Trail is “more” of a ludic narrative than Adventure, even as we recognize both to basically fit the category. Simply put, the narrative component of The Oregon Trail, the importance of its narrative dimension to both author and player, feels much more significant. There may also be edge cases which fail one of the tests, but which still have the “feel” of ludic narrative. As long as we’re reasonable about these things, it seems pointless to exclude them from discussion because of some arbitrary checklist. So, we can have our scientific definition of a ludic narrative and our instinctual definition, and mix and match and apply them as seems most useful, letting each inform both our understanding of the other and our understanding of the form.

Of course, the modern world of videogames is very different from that of the 1980s. Out of our group of four, text adventures are, at least as of this writing and with a bare handful of exceptions, no longer commercially marketed, while traditional graphic adventures have retreated from near the center of the gaming universe in the early 1990s to a decidedly niche form today. More interestingly, absolutely heaps of videogames, very possibly the majority, now fit into the category of ludic narratives, at least by our “scientific” definition. (Whether Flo’s Fix-It Scramble XXVI: Build a Cake, with the simplistic story it uses to structure its levels, really feels like an exercise in ludic narrative is another matter.) If some of the traditionally story-oriented forms of game have retreated from the mainstream, their absence is more than made up for by the piles of first-person shooters, real-time strategy games, and casual tycoon games that now also want to be narrative experiences to one degree or another. One thing that I hope will emerge over time from this blog is a picture of how that happened.

In my next post I plan to work out a couple more theoretical ideas that will complement what I’ve just written and hopefully make the thrust of all this much clearer.

The Rise of Experiential Games
July 22, 2011

Having introduced my ideas about what constitutes a ludic narrative in my last post, I’d now like to set that aside for just a little while to consider games in another way.

I define a game as a dynamic system which, in contrast to other art forms (sorry, Roger Ebert) which are “merely” consumed and appreciated, requires active input from one or more players to make it go. I realize that such a definition excludes some things often referred to as games, such as children’s free-form “games” of pure make-believe, and potentially lets in some questionable things, such as some interactive art installations. We’ll just have to use a bit of common sense in applying this definition, and where necessary fall back yet again on good old George Lakoff.

I think we can usefully divide a game into three components. First we have the system itself, the network of rules which govern play and, indeed, which largely mark the game as a game. Next we have what Noah Wardrip-Fruin calls the surface, the player’s method of getting data into and out of the underlying system. Taken at its most superficial, the surface of a given game can often be described in a few words: a poker player uses the playing cards for both input and output, for instance, while a player of a modern computer game likely uses the mouse for input and the monitor screen for output. However, I really mean for the surface component to be taken more holistically, to be used to cover not only the bare technology of interaction but also the character of that interaction and the scope of affordance (in game-designer speak, the “verbs”) that is allowed. This seems only reasonable; a first-person shooter, for example, provides its own very distinct experience at the surface level, one that is in some ways richer and in some ways more limited than, say, a point-and-click graphic adventure game. And finally, we have the fictional context of the game, the imaginary event being simulated. (Many games are, of course, based on real-life events, but even these must play out anew in the players’ imaginations.) It’s this aspect of games that is one of the keys to my idea of ludic narrative.

The first thing to note about fictional context is that its relative important to the experience of a game can vary tremendously. In some cases context may not be present at all. Poker and most other traditional card games, for instance, exist purely as abstract systems to be manipulated. Many other games do provide some sort of context, but said context has little relation with the system of rules, being (to use some board-gamer parlance) essentially “painted on” and quickly forgotten during actual play. The board game Monopoly is a classic example of this phenomenon that virtually everyone knows. My wife and I actually play quite a lot of board games, including many examples of so-called “Euro-games” whose elaborate themes and colorful artwork almost always have nothing whatsoever to do with the actual experience of play. I don’t mean this as a criticism; I think I could play Dominion every day for the rest of my life and not tire of it. In this blog, though, I’m obviously most interested in games that have a context that is very important to the player’s experience.

We can legitimately call all such games simulations, in that their rules systems simulate events occurring in a fictional place that exists only in the imagination of the players. They can perhaps trace their oldest progenitor to ancient China, where Sun Tzu, the author of The Art of War, developed a game which simulated the maneuvering of armies in order to help his students learn strategy. It is possible that this game, which Sun Tzu named Wei-Hai, evolved into the abstract strategy game Go over the centuries. Similarly, the modern game of chess, which bears only the merest vestiges of a context in the iconography of its pieces, may have evolved from some other game meant to at least semi-realistically simulate real military strategy.

That and a handful of other historical possibilities aside, the origin of the simulation game as we know it today can really be traced to approximately 1800, when a Prussian writer named Georg Viturinus developed a game he called simply neues Kriegsspeil (“new wargame”). Played on a board of 3600 squares and with some 60 pages of rules, Viturinus’s Kriegsspeil was probably the most complex game ever developed up to that point. Unlike earlier games which dealt with military strategy in the abstract only, Kriegsspiel was relentlessly specific; its game board, for instance, consisted of an accurate map of the Franco-Prussian border, while it endeavored to accurately portray the strengths and weaknesses of the various French and Prussian army units which served as the players’ “pieces.” By 1812 a military office named Georg Leopold von Reiswitz had refined the game and begun demonstrating it to other officers, hoping to get it adopted as a standard tool for training and strategic and tactical planning. By 1824 a standard set of rules written by von Reiswitz and his son had indeed been adopted, and presumably contributed to the Prussian military’s genius for making war with cold, surgical efficiency. And by 1875, wargames had become standard tools of militaries around the world.

If these games had a very serious — indeed, a deadly — purpose, they were also to certain kinds of minds immensely appealing as intricate systems to be tinkered with, as engines of imagination. Some thus took up wargaming as a hobby, developing elaborate systems of rules which they often played out using carefully carved and painted miniatures representing armies or ships. H.G. Wells was so fascinated with the burgeoning hobby that he published his own set of house rules as the book Little Wars in 1913. Still, the golden age of wargaming began in earnest only in 1954, when Charles S. Roberts founded Avalon Hill to publish the game he had developed, Tactics, the first widely available wargame sold as a set of rules, boards, and pieces ready to play right out of the box. From that beginning sprang a hobbyist network that grew to considerable size, peaking right around the time that the TRS-80 and its rivals from Apple and Commodore were introduced. In fact, 1977 was the year that Avalon Hill released Squad Leader, the most successful wargame of all time with more than 200,000 copies sold. Alas, the trend for non-electronic war games from that point on was a fairly steadily downward one… but that’s a story for another time.

As befits their origin and their label, most of these games dealt with armed conflict of one stripe or another, simulating battles from Marathon to the Golan Heights, and wars from the Trojan War to (a hypothetical) World War III. Some, however, simulated other fields of endeavor, from business to politics to sports. Still others acted as simulations of events which had no real-world antecedents at all, portraying battles in space between alien empires or fantasy conflicts in which mages provided artillery fire and dragons gave air support.

In a wargame, the system of rules is absolutely subservient to the context; indeed, virtually all of the rules derive directly from the context. This is a fascinating and hugely important shift. Think of the rules of chess, so perfectly honed, so balanced and elegant that artists and scientists alike have found them almost irresistably alluring for centuries. Now consider the rules of a complex wargame like Squad Leader, a web of data charts and matrices, of fiddly rules with pages full of exceptions and special cases. Further, in the name of faithfulness to history most sessions of Squad Leader must begin with the deck literally stacked in favor of one side or the other, in terms of numbers, quality of men and material, positioning, etc. Taken as a game qua game, it’s absolutely terrible. Why would anyone want to bother with this mess in lieu of the classical elegance of chess? The answer to that question involves nothing less than a shift in the very nature and purpose of a game.

When we think of playing a game, we still even today envision by default an intellectual and/or physical struggle against one or more opponents, with the goal being to secure victory and glory for ourselves. How remarkable to consider, then, that at the height of wargaming’s glory days prolific designer James F. Dunnigan found in a survey of players that the majority played most of the time solo, moving each side in turn. He provides some reasons for this in The Complete Wargames Handbook:

The most common reasons for playing solitaire are lack of an opponent or preference to play without an opponent, so that the player may exercise his own ideas about how either side in the game should be played without interference from another player. Wargames are, to a very large extent, a means of conducting historical experiments.

The attraction of a wargame is not, as with the context-less chess, found in the system itself, nor even in the proverbial thrill of victory and agony of defeat. They are rather attractive as engines for imagination, and for the reenactment and manipulation of history. Their appeal, in other words, is rooted entirely in their context; divorced from that context, the rules of Squad Leader would be of interest only as a candidate for Worst Game Design Ever. But with it, they are, at least to a certain kind of person, a gateway to history full of infinite possibility and fascination. Wargames are the first experiential games, the first to be ultimately all about the experience of their context. We play and appreciate chess strictly as an abstract system. We do not imagine a knight slaying a pawn; drama derives from the contest of intellect and will we are engaged in with the very real opponent seated across the table. Wargamers, however, use them as a window to another realm; they see the battle playing out in their mind’s eye, and the most imaginative of them even smell the blood and cordite in the air. A popular past-time of wargamers since the dawn of the hobby has been the creation of after-action reports describing particularly exciting sessions. Some of these go far beyond mere notes of moves and countermoves to get quite elaborate indeed, chock full of unusual characters and colorfully described action.

So, are wargames narrative experiences? Well, and while trying not to fall afoul of the painfully tedious academic debate between ludologists and narratologists, it’s hard for me to consider them anything else. Certainly history, at least as it’s generally presented in popular literature, is essentially a narrative. And I don’t think it’s a coincidence that in the two non-English languages I somewhat know, German and Danish, the word for history is the same as the word for story. That said, wargames obviously don’t qualify as ludic narratives as I’ve chosen to define that term, for their players manipulate their worlds from on-high, like gods looking down into their simulated worlds, rather than actually entering said worlds to play a role there. As one might expect given their origins and their style of play, they are more akin to interactive historical texts than interactive novels. While they are engines of narrative, they aren’t narratives in themselves; more on this distinction later.

I’m (slowly) getting to the point where experiential games spawned ludic narrative, but first there’s one more historical thread I have to run down. I’ll do that next time.

Dungeons and Dragons
July 28, 2011

Although wargames were sold commercially from 1954, and at least the big players like Avalon Hill made considerable profits from them, much innovation in the field was driven by a network of active, committed hobbyists who formed clubs and held meet-ups to swap stories, tweaks, miniatures, and even whole new games amongst themselves in ways not so different from early computer enthusiasts like the Homebrew Computer Club.

In 1959 a Harvard Law School dropout named Allan Calhamer self-published a game of his own design, Diplomacy, in a 500-copy run. Set in Europe on the eve of the First World War, this grand strategy game might at first seem a fairly typical entrant into the burgeoning wargame hobby that Avalon Hill had opened up just a few years before. Each player controlled one or more of seven possible countries, with the ultimate goal being the military conquest of Europe. A closer look, however, revealed a very unusual design indeed. In this game the management of armies and the mechanics of conquest were almost an afterthought. Instead the real meat of the game, as its name would imply, centered on social interactions and negotiations amongst the players. Every Diplomacy player is actively, explicitly asked to embody the leader of a European power in negotiations with his peers. Other wargames had and would continue to make superficially similar requests, implicitly and sometimes explicitly; the box copy of 1964’s Afrika Korps, for instance, states, “Now YOU command in this realistic desert campaign game by Avalon Hill.” However, playing Rommel in Afrika Korps ultimately still came down to just moving bits of cardboard around a game board; no one came to a session dressed in a German army uniform and proceeded to rant about the interference of Hitler and his cronies back in Berlin. Yet exactly this kind of theater was common among hardcore Diplomacy players. After being picked up by a real publisher a couple of years later, Diplomacy went on to become an enduring classic that is still sold and played today.

A major hotspot of early wargaming was the American Midwest, where organizations like the Midwest Military Simulation Association and the Lake Geneva Tactical Studies Association were springing up in numbers by the mid-1960s. A particularly active member of the former group was a university physics student and Minneapolis-area resident named Dave Wesely, who devoured not only the products of the wargame industry but also whatever literature he could find in the library pertaining to the still nascent field of game theory. In 1967 he combined ideas from a number of sources to create what was arguably the first true ludic narrative.

The game Braunstein started like a rather typical wargaming scenario, with Wesely preparing a detailed game board representing the area around the fictional Prussian town of Braunstein. At the heart of the game would be a hypothetical battle between the invading forces of Napoleon and a Prussian garrison defending the town. Its fictional rather than historical scenario was a bit unusual, but hardly unheard of in wargame circles. What marked the game as truly unique were the innovations Wesely deployed around the tried and true wargame framework, some of which he owed to Diplomacy.

In the fashion of that game, Wesely asked each of his players to embody the role of someone in his scenario. Two of these roles were obvious: the commanders of the two opposing armies, standing in for the leaders of nations of Diplomacy. Wesely, however, took the role-playing aspect much further this time, also creating roles for an advance scout for the French army; for the town’s mayor, concerned not so much with military glory as with minimizing the death and destruction the battle would visit on his town; for the local university chancellor; even for some university students of questionable loyalty and with radical agendas of their own (shades of the real-life political milieu of 1967). To facilitate all of these disparate personalities and agendas, Wesely acted as an impartial referee for the group as a whole. First he pulled each player aside before the game began and gave him a quick sketch of the personality and the goals of the character he would be play; later, during the game itself, he oversaw everything, informing the different players of what was going on from their perspective to maintain a “fog of war” and, of course, performing as judge and jury for everything that transpired. That was the plan, anyway; in the first actual play of Braunstein something close to complete chaos reigned. Sean Patrick Fannon described the scene in The Fantasy Roleplaying Gamer’s Bible:

Wesely had not counted on the imagination and enthusiasm of his players. They were almost immediately enchanted with the idea of assuming a single role with special and secret goals. Within minutes of the game’s start (in fact, even before it got officially underway, I am given to understand), player were off in various corners of the house conspiring and discussing with one another.

In a sense the negotiations and betrayals that transpired were not all that far removed from an enthusiastic session of Diplomacy. However, Braunstein was different in rooting its context in such a specific fictional scenario, and in offering the players such a smorgasboard of distinctly defined fictional personalities to play. And unlike Diplomacy, which was ultimately a zero-sum game with winning and losing sides, the goal of Braunstein was really just to play, to inhabit a character in this storyworld. More from Fannon:

When Wesely got wind of what was happening, he tried to reign it in. People would come and ask him things out of turn; when he asked how it was the University student was in communication with the advance French scout (since his miniature was still in the town), the player shrugged and said, “Let’s pretend that I swam the river and got out there, OK?” Wesely, trying to ensure everyone was having a good time, endeavored to acquiesce as much as possible.

Wesely actually left that first play session dejected, believing the structure of the game to have broken down so badly that the result couldn’t have been satisfying for anyone. In this he was mistaken; players were soon begging him to do it again. After running several more sessions, Wesely joined the Army and left Minneapolis. By the time he did, though, his new approach to gaming had infected his friends. Amongst the biggest fans of the new approach was a fellow named Dave Arneson, who took up the mantle of Braunstein and began running sessions of his own, first using Wesely’s original scenario and then others of his own devising.

Arneson was in some ways an ideal figure for the task. Unlike many wargamers, who could obsess for hours over the most minute of rules, Arneson was interested in game design only so much as it allowed him to open up storytelling vistas for the imagination; he was the prototypical context-focused gamer, in for the fictional experience being simulated rather than any fascination with the underlying game system. A similar impulse drew him to the writings of an author who was exploding in popularity during the late 1960s, J.R.R. Tolkien. His interests being what they were, Arneson gradually began to drift away from the military themes of traditional wargaming toward Tolkienesque fantasy. By 1970 he had created a fantasy realm of his own, which he called Blackmoor, to play host to a long-term campaign, in which his players could live out entire careers for their characters via a series of interconnected adventures. His players liked the idea, and loved the rich tapestry of politics and history and ecology Arneson wove into Blackmoor, but on a practical level play there was difficult and frustrating. Arneson’s strength was the soft art of world-building rather than the hard science of rules design. With no established rules to draw upon, as had been the case with his more wargame-like scenarios, he was largely reduced to making things up as he went along, a process that felt capricious and arbitrary to his players. So, Arneson and friends went looking for some rules they might adapt for Blackmoor. They found them in a little black and white booklet called Chainmail: Rules for Medieval Miniatures and in particular in its Fantasy Supplement, which featured rules for magic use and a roster of mythical creatures to battle.

Chainmail was itself a product of the Midwest wargaming scene, published by a tiny company called Guidon Games, based in Indiana. In fact, Arneson knew Chainmail‘s principal author very well, having already collaborated with him on a Napoleonic naval game called Don’t Give Up the Ship! His name was E. Gary Gygax.

Gygax was a twenty-year-old odd-jobber and sporadic university student in 1958, when he discovered one of Avalon Hill’s earliest games, Gettysburg, on a shop shelf in Chicago. A pedantic, somewhat fussy personality with little use or patience for conventional classroom education, Gygax had been throughout his life fascinated with the workings of complex systems. Had he been exposed to computers early in life, there’s a good chance he would have become a natural hacker. Since he was not, though, he did his hacking on games. Chess was his first love, but Gettysburg opened his eyes to a whole new world of ludic possibilities. Even as he married and settled down to father five children, Gygax devoted more and more energy to the hobby, not just playing regularly but tinkering with and occasionally publishing via the fan press rules, scenarios, and philosophy. In 1966 he co-founded the grandiosely named International Federation of Wargamers. In 1968 he organized the first edition of an annual wargaming convention, Gen Con, held in the erstwhile hometown to which he had recently returned, the Wisconsin resort town of Lake Geneva. By this time Gygax was one of the leading figures in hobbyist circles, especially around the Midwest.

It’s probably an oversimplification to say that Dungeons and Dragons was a combination of Arneson’s imagination and big-picture theorizing and Gygax’s attention to detail and rules lawyering, but certainly that seems to describe the general thrust of each man’s contributions. By 1972 Arneson had progressed beyond merely adapting Chainmail to his purposes to regularly meeting and corresponding with Gygax to develop a whole new system of rules. Together they abandoned the traditional wargame mechanics of Chainmail, in which every playing piece represented about 20 soldiers, to develop a game that took place largely in the imagination rather than on the tabletop, one in which every player assumed the role of single individual in the storyworld, interacting with one another and the rest of the storyworld under the guidance of a referee. Arneson was not always patient with Gygax. (“He literally had a small book on different kinds of polearms, which I regard as the ultimate in silliness,” Arneson once said. “It’s a pointy thing on the end of a stick!”) Still, in this formative period D&D needed Gygax’s rigorousness as much as it needed Arneson’s world-building vision. In a decision he would later have great cause to regret, Arneson largely left it to Gygax to document their innovations, and to publish them under his own tiny Tactical Studies Rules (TSR) imprint in January of 1974.

It took TSR nearly two full years to sell the first 4000 copies, but by the end of the decade TSR and Dungeons and Dragons were growing together at an almost exponential pace, while Arneson was suing his erstwhile partner in hopes of getting a piece of the action he had co-created.

Whenever Dungeons and Dragons is mentioned in the popular media it’s done with a certain jeering tone, dredging up old stereotypes of nerds in dank basements with no social lives and serious personal grooming issues. It’s hard for me to really blame them because, let’s face it, it’s very hard to write about D&D without making fun of it just a little bit. The default voice of early D&D is the precise but gracelessly stilted, pseudo-academic diction of Gygax himself, channeled by others in organs such as TSR’s own Dragon magazine in long, earnest articles on such pressing questions as whether magic and science are compatible in the world of D&D, or (keeping with the theme) how magic and women interact, two subjects doubtlessly equally mysterious to most Dragon readers. (“Female thieves are the same as male except that higher level female thieves can learn some limited magic, and Beautiful thieves are capable of the spells of seduction and Charm Men.”) Another early article delivers the blow that “Gandalf was only a fifth-level magic-user,” an example of a disconcerting tendency to reduce the abilities of great characters of fiction to a set of numerical attributes. (The same article informs us that Sauron himself was “no more than 7th or 8th level,” concluding that Middle Earth must be run by a “very tough DM [referee]”, under whom it took “2000 years for a pseudo-angel to get to the 5th level.”)

At the same time, though, D&D was pretty amazing, as the first full-fledged system for ludic narrative, an engine upon which referees (“dungeon masters,” the sort of phrase only Gygax could come up with non-ironically) could craft interactive stories for their players. Gygax wrote in 1979:

At the risk of claiming too much for the game, I have lately taken to likening the whole to Aristotle’s Poetics, carrying the analogy to even more ridiculous heights by stating that each Dungeon Master uses the rules to become a playwright (hopefully of Shakespearean stature), scripting only plot outlines, however, and the players become the Thespians. Before incredulity slackens so as to allow the interviewer to become hostile, I hasten to add that the analogy applies only to the basic parts of the whole pastime, not to the actual merits of D&D, its DMs, or players. If you consider the game, the analogy is actually quite apt. DUNGEONS & DRAGONS is like none other in that it requires the game master to create all or part of a fantasy world. Players must then become personae in this place and interact with the other populace. This is, of course, a tall order for all concerned — rules, DM, and players alike.

He may be insufferably smug, but Gygax is right. In fact, while we’re indulging in grandiose statements I’ll say I consider D&D to represent, without hyperbole, nothing less than the first of a whole new art form. I’d also say that its impact on the culture at large has been, for better or for worse, greater than that of any single novel, film, or piece of music to appear during its lifetime.

But of course that impact would not come via its original tabletop incarnation, but only once its core ideas and mechanics had been translated into computerized versions. Again, Gygax himself saw the potential:

DUNGEONS & DRAGONS can be played on a computer. Computers are most certainly a big aspect of the near future, particularly the home computer. Non-programmable computer games are already making big inroads into the toy and hobby market. They will grow still more, and soon programmable games will join this trend. D&D program cassettes plugged into a home computer would obviate the need for a DM or other players. Thus the labor of setting up a campaign or the necessity of having a fairly large group to play in it would be removed. The graphic display would be exciting, and the computer would slave away doing all of the record work and mechanics necessary to the game, giving nearly instantaneous results to the player or players. Computerization of D&D has many other benefits also, and such games would not destroy the human-run campaign but supplement game participation. This is the direction we hope to make available to D&D. Let’s see if my foresight is as keen as my hindsight.

We’ve already seen one example of D&D directly inspiring a seminal early computer game, in the form of the original Adventure, whose creator Will Crowther was a very early fan of the game. Adventure, however, and the many text adventures that followed it, took mainly thematic and conceptual inspiration from D&D. By the time the words above appeared in the February, 1979, issue of Dragon, others were attempting to translate the game more literally. I want to begin to look at those efforts next.

Defining the CRPG
August 14, 2011

There’s a whole lot of Dungeons and Dragons in the original Adventure. Its environs may be based on Kentucky’s Colossal Cave, but the central premise of exploring and looting an underground environment filled with strange dangers and treasure has as much to do with D&D as it does with caving. Even some of the ways in which that environment is presented are strikingly similar. A typical D&D dungeon was, like Adventure‘s, divided into a series of discrete, self-contained rooms. Here’s one of the maps that accompany Temple of the Frog, the first published D&D “adventure module,” which appeared as part of the second D&D supplement, Blackmoor, in 1975:

And here’s the description of a couple of these numbered rooms:

Room 3: Is the headquarters of the traders sent out to sell the junk and is also the office of the chief of accounting. Hidden in this desk are 600 pieces of platinum that he has embezzled. (The High Priest knows about this but does not seem to care.)

Room 4: Is the office of the Commander of the palace guard where he goes to run the security arrangements in the Temple. Within are the master alarms for the palace, so that the exact location of trouble can be registered and personnel sent to counter the intrusion. From here he can communicate, via a desk communicator, with other officers and sergeants under his command. There is always an officer and two sergeants on duty in this room and only the rings worn by the High Priest Command of the Guard or the Chief Keeper will gain admittance. (No one is aware that the latter has such a privilege, and it has not been used for many years.)

Later D&D adventures made this similarity with the IF room even more obvious by including a boxed text with every room that the DM should read to the players upon their first entering, just like the ubiquitous IF room description. At least under all but a very skilled DM, the rooms of a D&D dungeon tended to feel oddly separate from one another, each its own little self-contained universe just like in a text adventure; many was the party that fought a pitched battle with a group of monsters, then, upon finally vanquishing them, stumbled upon some more still slumbering peacefully in the next room just as the room description said they should be, undisturbed by the carnage that just took place next door. Speaking of combat, the heart of most D&D adventures, Adventure even had a modicum of that as well, in the form of the annoying little dwarfs that harried the player until they were all dispatched.

For all these similarities and for all the acknowledged influence that his experiences as a D&D player had on Crowther’s original work, though, virtually no one refers to Adventure or its many antecedents as computer RPGs. What gives? One thing we might take note of is that Crowther made no real attempt to translate the actual D&D rules into his computer game. He took inspiration from some of its themes and ideas, but then went his own way, whereas the mechanical debt that the family of games I now want to begin to cover owed to D&D was as important as the thematic debt. Just leaving it at that seems a bit unsatisfying, though. Maybe we can do a little bit better, and in the process come up with something that might be useful in a broader context.

Matt Barton says something really interesting in the first chapter of Dungeons and Desktops: The History of Computer Role-Playing Games:

To paint with a broad brush, we could say that the adventure gamer prioritizes deductive and qualitative thinking, whereas the CRPG fan values more inductive and quantitative reason. The adventure gamer works with definitions and syllogisms; the CRPG fan reckons with formulas and statistics. The only way for a character in a CRPG to advance is by careful inductive reasoning: if a certain strategy results in victory in six out of ten battles, it is better than another strategy that yields only three out of ten victories. This type of inductive reasoning is rare in adventure games but is plentiful in CRPGs, where almost every item has some statistical value (e.g., a longsword may do ten percent less damage than a two-handed sword, but allows the use of a shield).

These differences in thinking arise of course from very different approaches to game design and narrative on the part of the works’ creators. The typical adventure-game designer spends most of her time crafting a pre-defined experience for the player, building in a series of generally single-solution set-piece puzzles and a single (or, at most, modestly branching) narrative arc. The CRPG designer, meanwhile, pays less attention to such particulars in favor of crafting an intricate system of rules and interactions, from which the experience of play, even much of the narrative, will emerge. CRPGs, in other words, are essentially simulation games, albeit what is being simulated is an entirely fictional world.

At first blush, there perhaps doesn’t seem to be any room for debate about which approach is “better.” After all, if given a choice between jumping through hoops to progress down a single rigid path or crafting one’s own experience, writing one’s own story in the course of play, who would choose the former? In actually, though, things aren’t so clear-cut. There are inevitable limits to any attempt to create lived experience through a computer simulation. It’s perfectly feasible to simulate a group of adventurers descending into a dungeon and engaging in combat with the monsters they find there; it’s not so easy to simulate, say, the interpersonal dynamics of a single unexceptional family. People have tried and continue to try, but so far the simulational approach to ludic narrative has dramatically limited the kinds of stories that can be interactively lived. Thus, the simulational approach can paradoxically be as straitening as it is freeing. And there’s another thing to consider. The more we foreground the simulational, the more we emphasize player freedom as our overriding goal, the further we move from the old ideal of the artist who shares his vision with the world. What we create instead may certainly be interesting, even fascinating, but whatever it ends up being it becomes more and more difficult for me to think of it as art. Which is not to say that every game design should or must aspire to be art, of course; given my general experience with games that explicitly make claims to that status, in fact, I’d just as soon have game designers just concentrate on their craft and let the rest of us make such judgments for ourselves.

I must be sure to point out here that “emergence” and “set-piece design” do not form distinct categories of games, but rather the opposite poles of a continuum. Virtually every game has elements of both; consider the scripted dialog that appears onscreen just before the player kills the Big Foozle in a classic CRPG, or the item that a player must have in her inventory to solve the otherwise set-piece text-adventure puzzle. It’s also true that disparate games even within the same genre place their emphasis differently, and that over time trends have pulled entire genres in one direction or another. Here’s a little diagram I put together showing some of what I mean:

As the diagram shows, modern big-budget RPGs such as those from Bioware have actually tended to include much more set-piece story than their classic predecessors, in spite of the vastly more computing power they have to devote to pure simulation. (There’s some great material in Noah Wardrip-Fruin’s Expressive Processing about the odd dichotomy between the amazingly sophisticated simulational part of a game like Knights of the Old Republic and the limited multiple-choice conversation system the player is forced into whenever emphasis shifts from the hard mechanics of exploration and combat to the soft vagaries of story and interpersonal relationships.) Modern IF has also trended away from simulation, de-emphasizing the problems of geography, light sources, inventory management, sometimes even combat of old-school text adventures to deliver a more author-crafted, “literary” experience.

But I wanted to define the CRPG, didn’t I? Okay, here goes:

A computer role-playing game (CRPG) is an approach to ludic narrative that emphasizes computational simulation of the storyworld over set-piece, “canned” design and narrative elements. The CRPG generally offers the player a much wider field of choice than other approaches, albeit often at the cost of narrative depth and the scope of narrative possibility it affords to the designer.

At least for now, I think I’m going to leave it at that. Most other definitions tend to emphasize character-building and leveling elements as a prerequisite, but, while I certainly acknowledge their presence in the vast majority of CRPGs, it seems limiting to the form’s possibilities to make that a requirement. Of course, I could have also simply used the definition we used in the 1980s: in adventure games you explore and solve puzzles, in CRPGs you explore and kill monsters. But that’s just too easy, isn’t it?

So, we hopefully now have some idea of what it really is that separates a CRPG from he works of Crowther and Woods and Adams. With that in place, we can begin to look at the first examples of the form next time.

From the Tabletop to the Computer
August 16, 2011

Let’s say that it’s the mid-1970s, and that you’re an early fan of Dungeons and Dragons, still a tiny offshoot of the niche hobby that is wargaming. Let’s further say that you have regular access to a computer at your place of education or work, and that you know how to program it. It might seem absurd to imagine a substantial overlap between the tiny number of people playing D&D circa 1975 and the decidedly limited if not quite so miniscule number who had access to a computer at that time, but in fact Will Crowther was hardly an anomaly; there was an inordinate number of hackers among early fans of the game. We can assume that hackers’ love of complex systems brought them to the game, just as it drew them to fantasy and science-fiction literature such as the works of Tolkien, where character and plot were subservient to (or at least equal in importance with) world-building.

So, we have a substantial number of hackers entranced with D&D. Hackers being hackers, it’s not difficult to guess what happened next: various projects got under way to bring the experience of D&D to the computer. This was a task for which, depending on how you looked at it and to whom you talked, the computer was either ideally suited for or woefully unequipped to handle. We’ll take the best-case scenario first.

D&D was complicated. Even the original 1974 rules, which virtually everyone agreed were crude and sketchy in many areas, filled three separate booklets of about 35 pages each while recommending that the players also have on hand a copy of Gygax’s earlier Chainmail rules. But that was only the beginning. Just the core of Advanced Dungeons and Dragons, the definitive rules for the hardcore which TSR rolled out over the last three years of the 1970s, ran to hundreds of pages housed in three big, close-typed, hardcover volumes. To this ample base were added layer after layer of further embellishment via yet more hardcover volumes and an endless stream of Dragon magazine articles. It’s fair to say that a certain subset of D&D players — those who took after Gygax himself — absolutely reveled in all of this minutiae. Indeed, for some players the baroqueness of the whole endeavor was the major part of its appeal. Plenty of others, though, were like Arneson, in it for the visceral thrill of lived (if imaginary) experience. When they mustered their last bit of carefully hoarded mana to cast Cone of Cold, their last memorized spell, on the Lizard King (apologies to Jim Morrison), these players did not want to spend ten minutes cross-referencing manuals, calculating probabilities, and pondering such unsolvable existential conundrums as just why the hell an armor class of -5 was vastly better than an armor class of 10. They just wanted to know whether their spell sputtered and died, taking it with it their party’s last hope, or whether the Lizard King had been turned into a giant green popsicle. Computers were pretty good at crunching numbers, and happy to apply even the most obtuse of rules to them. What if all of those tedious bits could be stuck into the computer, programmed and tinkered with by the Gygax-types of the world who enjoyed such things, leaving the Arnesons of the world free to just play? As an added bonus, the use of a computer might mean they could play all alone on their own time if they wanted to, rather than needing to assemble four or five friends. It seemed like a dream come true.

But wait a minute, said the naysayers (a group which included, ironically, many of the most committed Arnesons). One of the major things that defined D&D as different from any game that had come before was the sheer scope of possibility it offered to its players. A player was free, theoretically at least, to do absolutely anything she wanted to at any time. It was then up to the DM to find the rule he felt applied best from the small library he had lugged with him to the session. Failing that, he had to use his judgment to make up something appropriate on the spot. (We could note at this point that all of those rules TSR was constantly pumping out could never come to cover every concievable situation anyway, and that there must come a point of diminishing returns where just making things up in such unusual circumstances was preferably to buying yet more rulebooks in the forlorn hope of covering all the bases, but let’s just let that go.) A computer, of course, can’t make judgment calls; it can only do what it’s been programmed to do. Further, it cannot appreciate the dashing rogue of a leather-clad thief with a severe aversion to wood elves (a case of childhood trauma) you have so creatively personified. It cannot craft an adventure into the heart of the forest just for you, during which Dirk Darkstone will have to confront his horror of effeminate green-clad men wielding bows. It can’t even provide you with Tasha Brightstone, the virtuous blonde paladin in the chainmail bikini torn between her desire for Dirk and the Code of the Virgin Warrior to which she has signed her name. Every computer program ever created, games included, must ultimately offer the user only the limited menu of possible actions anticipated by its designer. Whether that set consists of the up-and-down trackball motions of Pong or the various verbs a text-adventure designer has coded his game to recognize, this constraint is immutable. How then can a computer administer a game whose players can do literally anything? The gospel of tabletop D&D tells us that, even when presented with a tempting dungeon to plunder by the DM, the players are perfectly free to walk on past the Ominous Castle of the Mad Wizard Yordor and spend the evening trying to get a really good brawl started in the local tavern instead. So, the Arnesons of the world tell us, D&D and the computer are not such a marriage made in heaven. The computerized D&D player could avoid the Mad Wizard only by turning off the computer and doing something else, after all.

We’ve certainly hit upon a significant limitation, but let’s think about all this again before we go too much farther with that train of thought. I submit that in practice the players of D&D are restricted in their field of action, by social if not rules-derived constraints. How would you feel if you were that DM who had spent his entire weekend designing the Castle of the Mad Wizard Yordor, stocking it with fearsome monsters (but balanced to not be too much for the players to handle if they play it smart) and devious traps (but not so devious they cannot be disarmed most of the time by a thief of exactly the same level as Dirk Darkstone if he is cautious), only to have your players march on past the lot to go grope the local chicks in the pub? I’m guessing you’d consider the players a bunch of ungrateful bastards whom you’d just as soon not play with again. Thus, there is an implied social contract between DM and players, one in which the players, at least in the broad strokes, are expected to, well, do what is expected of them.

Further, I submit that the rhetoric of D&D as a form of improvisational storytelling and the reality of most player’s experience of the game were somewhat at odds. The AD&D Player’s Handbook tells us:

You interact with your fellow role players, not as Jim and Bob and Mary who work at the office together, but as Falstaff the fighter, Angore the cleric, and Filmar, the mistress of magic! The Dungeon Master will act the parts of “everyone else,” and will present to you a variety of new characters to talk with, drink with, gamble with, adventure with, and often fight with! Each of you will become an artful thespian as time goes by…

The “fight with” part of the extract above was the really important part to most players, the thing that defined the experience of D&D. TSR released at least a hundred adventure modules that had players descending into one thinly justified underground lair or another to kill things and take their stuff using the 23 pages of combat rules found in the Dungeon Master’s Guide alone, and exactly zero that principally involved talking, drinking, or gambling with new friends. Even Gygax seemed of two minds about the real point of D&D. For all the parallels he drew with Shakespeare and Aristotle, in practice he was a dungeon crawler all the way, dismissive of elaborate role-playing: “If I want to do that, I’ll join an amateur theater group.” I submit that D&D was in practice not mostly played by groups of “artful thespians,” but by scruffy teenage boys and men perfectly happy to remain Jim and Bob as they pondered the best way to kill that group of trolls in the next room. And that experience of D&D a computer could, within inevitable limits, simulate pretty well.

The First CRPGs
August 18, 2011

The CRPG form lacks an Adventure — an urtext universally known and acknowledged as its starting point. I can propose a couple of reasons why this is so.

CRPG fans have, some exceptions aside, generally not shown anything like the same dedication to documentation and historical preservation that marks the modern interactive-fiction community, which has perhaps prevented an accepted canon of historically significant works from appearing amongst the former as it has amongst the latter. Likewise, for all its enduring commercial popularity the CRPG has not acquired the same academic caché as has IF; it’s easier to justify study of a “literary” form like IF within the academy than it is a form that revolves around killing hordes of monsters and leveling up, no matter how much fun that process might be. Just as significantly, Adventure had the good fortune to become really, really popular. It was the Doom of late 1970s institutional computing, a game that absolutely everyone who spent any time within that culture had to know and probably tried to play at least once or twice. The early proto-CRPGs of the same era, of which there were a fair number, did not spread so widely and did not come to occupy the same storied place in hacker lore. Most were created on a pioneering system called PLATO (Programmed Logic for Automated Teaching Operations — how long did they work to make that acronym fit?), which linked hundreds of educational institutions around the U.S. together via thousands of dumb terminals, a handful of mainframe computers, and a central hub at the University of Illinois.

I could easily devote a whole series of posts to PLATO, the first sustained online community to connect everyday people — mostly students from elementary to university age — together. I’ll just give you the short version here, though, and mention that PLATO was remarkable indeed in many ways, laboratory of countless innovations, from the vision of computer-assisted instruction that spawned it in the first place to the uniquely user-friendly custom operating system it ran to its TUTOR programming language that let anyone design new “lessons.” Uniquely amongst institutional systems, its terminals offered graphics and, if your school had chosen to spring for some additional gadgetry, possibly even some sound and music capabilities. Originating all the way back in 1960, PLATO reached a certain level of maturity with the roll-out of the PLATO IV system in 1972, and grew rapidly in this incarnation throughout the 1970s. Its graphical capabilities made PLATO exceptionally suited for gaming in comparison to other institutional systems, which still generally relied on clunky text-only teletypes for input and output. Throw in the fact that most of these terminals were being used by students with a bit of time on their hands, and that they had the easy-to-learn TUTOR language at their disposal, and it’s not surprising that PLATO became something of a hotbed of game development immediately before the beginning of the PC era and even for some years thereafter. Amongst these games were the first attempts to bring the Dungeons and Dragons experience to the computer. They began to appear as early as 1975 — even before Will Crowther’s creation of Adventure.

The earliest of these games were created without proper authorization from PLATO’s administrators. Thus they had to hide out on the system under unassuming, workmanlike names such as pedit5 and m199h, with word of their existence being passed around in secret. Inevitably, as their popularity increased they attracted the notice of administrators and were promptly deleted. Luckily, what appears to be the original version of Rusty Rutherford’s pedit5 has been restored and made available by the folks at cyber1, a resurrected PLATO system accessible via the Internet.

As the first or second game of its type to appear, pedit5 has a decent claim to stand as the CRPG’s equivalent of Adventure. Certainly it’s of immense historical importance.

That said, the most long-lived and popular of these games, the one that first defined the experience of the CRPG for many in the same way that Adventure did that of the text adventure, came a bit later. Its name left no doubt as to its inspiration: dnd. A much more sustained and ambitious project than the one-off pedit5, dnd was initially written by Gary Wisenhunt and Ray Wood, then expanded and refined by Dirk Pellett. By October of 1976 it had reached a basically finished state, becoming a surprisingly complex experience and a very popular one amongst PLATO users; the counter of total plays bwas already almost to 100,000 at that time.

Dnd spawned a whole family of PLATO dungeon crawls which share their ancestor’s blissful unconcern with copyright. Nowadays the lawyers of the Tolkien estate would be all over Moria, Baraddur, and Orthanc.

It might make an interesting little exercise in platform studies to ask why the PLATO system hosted so many dungeon crawls, while text adventures became the diversion of choice amongst the hardcore hackers working on their DEC systems. A good part of the answer comes down to technological constraints: PLATO could do screen-oriented, graphical displays rather beautifully really, while the PDP line continued to rely on line-oriented output devices capable only of text. The broader implications of this for interactive-fiction fans, that gamers have always preferred their pretty pictures and will take them whenever they can get them over plain text, are perhaps too disquieting to dwell on. If it helps, though, it’s also true that the two computing cultures used incompatible hardware and communicated over wholly separate networks, thus keeping these two burgeoning gaming traditions wholly separate from one another before they began to mix in the great melting pot of the PC world. Adventure and dnd after all gave each of these communities, still very small by modern computing standards, plenty of inspiration and plenty to iterate on without leaping into whole other paradigms of play.

Similarly, the most popular platforms of the early PC era, the TRS-80 and the Apple II, initially hosted quite different strains of adventure. Thanks largely to the efforts of Scott Adams, the TRS-80 went in the PDP hackers’ direction to host the first text adventures to enter the home. The Apple II, meanwhile, the only member of the class of 1977 with graphics capabilities even close to those of PLATO, went in the direction of dnd. Given the sketchy documentation and the ad hoc nature of most software “publication” of that era, it’s extremely difficult to say with certainty what game marked the first CRPG to appear on the Apple II — and by extension the first to appear on a home PC. Synergistic Software’s Dungeon Campaign, which appeared right about the time that Adams was shipping off those first tapes of Adventureland, is probably the best candidate.

For our purposes, though, I want to stick with our faithful old TRS-80 for just a little bit more. Next time I’ll be taking a close look at the first commercial RPG to be developed and sold for that platform, The Temple of Apshai (1979). As an heir both to Dungeons and Dragons and the early CRPG tradition that began with pedit5 and dnd, Apshai will give us a chance to see how a CRPG of this very early era actually played.

Temple of Apshai
August 24, 2011

In 1978 a fellow named John Connelley purchased a Commodore PET to aid in the bookkeeping of the Dungeons and Dragons campaign he was running. When he got the thing home and perhaps realized that the 8 K wonder’s utility for such a purpose was limited at best, he was afflicted with a bit of buyer’s remorse at the money he’d spent on it. Since he loved games, he hit upon the idea of writing one for the machine. Even if he didn’t sell enough copies to make any real money, he could at least use the project to justify writing the PET off on his taxes as a “business expense.” Unfortunately, Connelley was a better programmer than a game designer, and so his initial attempts went nowhere. In the end he turned to one of his D&D players, Jon Freeman, for help. Freeman was in just the opposite boat: he had been working for several years as a freelance games journalist and had a strong aptitude for game design, but knew nothing about programming. And so a marriage of convenience was born.

The first fruit of this union appeared before the end of the year in the form of a space strategy game called Starfleet Orion. To release it, Connelley and Freeman formed Automated Simulations, the first software publisher dedicated solely to games. Starfleet Orion looks rather bizarre when viewed through modern eyes, seeming more a sort of ludic construction set than a completed videogame. Its manual lays out an elaborate back story to justify a dozen space-battles scenarios between two alien races. The setup and order of battle for each of these is given, tabletop wargame style, in the manual; as the first step before actually playing one must key all of this data into the program and save it to a blank cassette using a separate program called BUILDER. In a touch that seems particularly bizarre to modern sensibilities, the BASIC source code for the game itself is also given in full in the manual, in case the player wants to tinker or the cassette on which the game is housed gets corrupted. Not only is Starfleet Orion two-player only, but it requires quite a time commitment; the manual estimates the climactic scenario to require about six hours to play, with no provision for saving state. Freeman and Connelley addressed these issues at least somewhat with Invasion Orion, a more accessible sequel with provision for solo play that they released early in 1979.

The really big release of 1979, though, took them out of space and into the dungeon. For Temple of Apshai, they brought in a third partner from their D&D group, Jeff Johnson, to help with an even more ambitious game design. Apshai was to be a full-fledged CRPG, drawing from the PLATO tradition of games like dnd, but also, in keeping with its designers’ background, paying very explicit homage to the deeper tabletop D&D experience that had brought them together in the first place. Its manual opens with a description of experiential gaming that is drawn straight from the tabletop RPG experience:

Role-playing games are not so much “played” as they are experienced. Instead of manipulating an army of chessmen about an abstract but visible board, or following a single piece around and around a well-defined track, collecting $200 every time you pass Go, in RPGs you venture into an essentially unknown world with a single piece — your alter ego for the game, a character at home in a world of demons and darkness, dragons and dwarves. You see with the eyes of your character a scene described by the “author” of the adventure — and no more. There is no board in view, no chance squares to inspect; the imaginary landscape exists only in the notebooks of the world’s creator (commonly called a referee or dunjonmaster) and, gradually, in the imaginations of your fellow players. As you set off in quest of fame and fortune in company with those other player/characters, you are both a character in and a reader of an epic you are helping to create. Your character does whatever you wish him to do, subject to his human (or near-human) capabilities and the vagaries of chance. Fight, flee, or parley; take the high road or low: the choice is yours. You may climb a mountain or go around it, but since at the top may be a rock, a roc’s egg, or a roc, you can find challenge and conflict without fighting with your fellow players, who are usually (in several senses) in the same boat.

Like the Orion games, Apshai foregrounds its experiential aspect. Games such as dnd quickly devolved into abstract exercises in tactics and strategy, with little thought paid to their fictional premise of dungeon exploration. Apshai, however, goes to great pains to try to get its player not to adapt that mindset. It plainly wants us to put ourselves right there in its dank dungeons, through the aforementioned proselytizing introduction; through an extended backstory justifying the existence of the dungeon you explore and describing a character you are free to imagine as your alter ego (“Brian Hammerhand”); and, most notably of all, through a set of D&D adventure module-style room descriptions the player is expected to read from the manual as she explores:

Room One — The smooth stonework of the passageway floor shows that advanced methods were used in its creation. A skeleton sprawls on the floor just inside the door, a bony hand, still clutching a rusty dagger, outstretched toward the door to safety. A faint roaring sound can be heard from the far end of the passage.

Unlike other early dungeon crawl games, whose dungeons were randomly generated or put together so haphazardly that they might as well have been, Apshai‘s dungeons are crafted to feel like a real place, even though that means that its monsters must be limited largely to sewer inhabitants (giant rats, various giant insects) and, on the lower levels that house the temple proper, various undead.

To be honest, all of this experiential gilding can feel a bit ridiculous to modern sensibilities because… well, to start, here’s what the actual game looks like in its original TRS-80 incarnation:

The fact that this display is a bit underwhelming is not the fault of Apshai‘s designers. The TRS-80 was limited to black and white (not gray-scale, mind — exactly two colors, black and white). Further, it wasn’t really capable of graphics at all in the way we think of them today, only character graphics. (In addition to a set of 64 commonly used English glyphs, it includes 64 more graphical tiles, each containing a simple abstract shape in lieu of a character glyph. By combining these together, it was possible to build larger pictures out of what remained essentially a text-only display.)

Viewed in the light of such a display system and the 16 K cassette-based computer on which it ran, Apshai is actually quite a technical achievement. Its rules also bear the stamp of an experienced game designer. They actually do not draw as heavily from D&D as one might expect given the game’s origins and the extended praise of the tabletop experience that fills its manual. While the expected six character attributes are present, and while they even number from 3 to 18 just like in classic D&D, combat and movement is very much its own thing here, a pseudo-real-time system that shows a willingness to harness the unique capabilities of the computer rather than just translate a pen-and-paper rules set into code. In fact, Apshai plays better in some ways than it has a right to; there’s a real tension to navigating through this labyrinth, deciding whether to press your luck and venture onward or turn for the exit, dreading the appearance of the next wandering monster as you do trudge back heavily wounded, having perhaps pressed your luck too far. There’s a visceral feel to the experience that many later dungeon crawls would fail to capture. This quality owes its existence partly to the real-time nature of play but hardly to other choices that have no counterpart in tabletop D&D. As your character loses health, for instance, he moves more slowly, gets fatigued faster, and becomes less effective, bringing home his state in a palpable way. Freeman’s design is a very smart one, in many ways very original even in comparison to games that would follow.

But there are inevitable limits to what even a smart designer can do on a 16 K TRS-80. One can easily forgive the fact that magic is not present at all in the game; the player is restricted to playing what amounts to the D&D fighter class. Of more concern is the fact that the two components of the game, the “Innkeeper” which is used for character management, and the “DunjonMaster” where the dungeon delving actually happens, don’t really talk to one another. The player is expected to keep a list of her attributes and the items she finds in the dungeon on each expedition, then enter those manually when she returns to the Innkeeper! Rather than being linked together, the four levels of the dungeon can each only be entered separately; there is absolutely nothing preventing the player from entering a super-character into the Innkeeper and starting out on level 4. There’s not much point to methodical exploration anyway, as there is absolutely no way to really win the game. For all its emphasis on the experiential, one cannot bring Apshai to any conclusion. One merely explores, levels up, and collects until one gets tired of the whole thing.

Still, even dictated as it is by technical limitations, there’s an odd sort of charm to Apshai. Rather than delivering a story, it really does expect its player to work with it, to build a story that exists as much in the imagination as it does in the computer. “Sure, you are free to ‘cheat’ and create a character with stats of all 18,” it says, “but what fun would that be?” Similarly, if the game doesn’t deliver an ending like we’ve come to expect, that doesn’t prevent the player from making up one of her own. There is an encounter on level 4 that feels kind of like a climax — or maybe the player just sets her own goal of visiting every single room and collecting every single treasure. Apshai expects you to work with it to make your own fun. Anyway, as Freeman wrote of a tabletop RPG campaign, “It never stops, except temporarily: there is no final victory, no point to playing except playing, and no ultimate aim except the continuing development of your character.” Why should the computer equivalent be any different? Indeed, if played as its designers imagined Apshai doesn’t really feel like a pure computer game, but some hybrid — a computer-assisted solo RPG rather than a CRPG, if you like.

In an article in Byte magazine, Freeman described the differences between the RPG’s simulational approach to narrative and the text adventure’s preference for set-piece design, while leaving little doubt which he preferred:

There is no real role-playing, for instance, in the Adventure/Zork family: the protagonist is just you in a strange setting. Games of that sort concentrate on the perceived open-endedness of action: not only is there a multitude of command options available (typically far more than Dunjonquest‘s eighteen or so), but also they are not made known to you except by trial and error. It can be quite challenging to find the right key, the right moment, and the right command necessary to insert it in the right lock; but once you do, the door will always open — always. Thus, a game like Adventure is really a puzzle that, once solved, is without further interest.

The Dunjonquest series employs a different approach. For one thing, situations are primarily defined graphically, not textually: you see the situation rather than just being told about it. More to our present purpose, while some Dunjonquest games, like Morloc’s Tower, have a specific object (finding and slaying the mad and elusive wizard Morloc), there is an open-endedness of result in all of them on the micro level (if you’ll excuse a small pun). Generally speaking, there are no “right” answers; the outcome of events is probabilistic, not predetermined.

Brian Hammerhand, the assigned alter ego/protagonist of Morloc’s Tower and The Datestones of Ryn, can, for example, slay a dire wolf nine times out of ten, but on any particular occasion he may survive the encounter unscratched, or limp away badly mauled and out of breath — and there is also that tenth time. Moreover, the exact outcome of any encounter depends both on the tactics you choose and on the specific traits of your surrogate character. The experience is different every time you play and quite different with each new character you take on your adventure. You are role-playing: getting outside yourself and into the skin of another (albeit imaginary) being.

The contention that the simulational approach leads to role-playing while the set-piece approach does not is highly suspect — although we should remember that at the time Freeman wrote this passage IF protagonists were universally of the “nameless, faceless adventurer” type. Still, the tension between the two approaches that Freeman describes here remain with ludic narrative right up to the present, often within the same design. We’ll doubtlessly be revisiting the topic many more times as we continue on this little historical journey.

If you’d like to experience Temple of Apshai for yourself, here are some instructions to get you started. Note, however, that you’ll need the patience of a saint; by modern sensibilities the original TSR-80 version is all but unplayable, what with the sloooooow speed of its screen updates and the aforementioned divide between the two halves of the program.

1. Download my neat little Temple of Apshai starter pack.
2. Start the sdltrs emulator.
3. Press F7, then load “newdos.dsk” in floppy drive 0 and “apshai.dsk” into floppy drive 1.
4. Reboot the emulator by pressing F10.
5. At the DOS prompt, type BASIC.
6. Type LOAD “INN:1”.
7. Type RUN.

The manual and quick reference card in the zipped download above should see you through the rest.

We’ll continue to check in on the developing CRPG in the future, but next time we’ll get back to text adventures, and see what our old friend Scott Adams got up to as the 1980s began.