Tag Archives: apple ii

I’ll be diving into Zork in some detail in my next post, but before I do that I just felt behooved to return in a bit more rigorous way to a subject I broached in my first post in this series: how impressive Zork was in the microcomputer world of 1980-81. I have a point I’m driving toward, one which involves a little bit of theory (uh oh!). But first let me set the stage with a few choice quotes from Jason Scott’s Get Lamp project.

“There were two products that sold more computers than anything else: VisiCalc and Zork.” — Mike Berlyn

“We would go after school to this store and play whatever games were available, type games in, and I remember Zork coming out and playing it on an Apple II, and we were just completely blown away.” — Andrew Kaluzniacki

“People would see Zork and say, ‘I gotta have me one of them, that’s all. Who do I make the check out to?'” — Mike Berlyn

“I think there was a time period, probably ’80 to ’84 sort of range, where, for a lot of the machines, compared to anything else out there, there was just nothing that compared.” — Mike Dornbrook

Yes, Berlyn’s placing Zork on a pedestal with the industry-defining VisiCalc is a bit over the top, but you get the picture. Statements like these read as ironic and maybe even a bit tragic today. Within a few years after Dornbrook’s 1980 to 1984 timeline, interactive-fiction publishers and fans would be lamenting IF’s lack of immediate, obvious appeal as the main reason for the genre’s declining commercial fortunes, amidst plenty of griping about the adolescent illiteracy of the typical videogame demographic and the like.

So, what did those early players find so immediately appealing about Zork? Certainly its world was not only bigger but modeled in a more rigorous, sophisticated way than anything that had come before. Certainly its writing, while often necessarily terse due to space constraints, showed a wit and nuance and, well, attention to basic grammar and spelling that eluded its competition. And certainly its design was, if still beset by infuriating mazes and some more-than-dodgy puzzles, also fairer than the norm. But these are things that text-adventure afficionados notice, the sort of things that only become clear after spending a few hours with Zork and (at least) a few hours with other games of its period. As the quotes above illustrate, people were playing Zork for a few minutes in shops and buying it in awe — and perhaps, Berlyn’s hyperbole aside, sometimes also buying the Apple II system they needed to play it. Why? I think the answer is bound up with the adventure game’s love-hate relationship with the parser.

In Joysprick, a book about James Joyce, Anthony Burgess divides authors into two fundamental categories. (Feel free to insert your own “two types of…” joke here; I’ll wait. Ready? Okay…) Class One authors are concerned exclusively with the storyworld — the virtual reality, if you will — that lives “beneath” their words. “Content being more important than style, the referents ache to be free of their words and to be presented directly as sense data.” “Good” writing, under this rubric, is writing that exists solely to serve the setting and the story it reveals, that evokes them as vividly as possible but that also gets out of the way of the reader’s imaginative recreation of the underlying virtual reality by diligently refusing to call attention to itself. Class Two authors, meanwhile, are concerned about their language as a end unto itself. Their books are “made out of words as much as character.” Sometimes, as in the case of Finnegans Wake or the “Siren” chapter of Ulysses, language seems like all there is — the writing is all “surface.” Some might say that being successful on this second level, or at least striving to be, separates “literature” from mere “fiction.” But let’s stay away from that can of worms. In fact, let’s try not to make any value judgments at all as we apply some of this to interactive fiction.

I don’t want to apply these ideas so much right now to the text that an IF game outputs to the player, but rather to the text that the player inputs — to the parser, in other words. One way to approach IF is as a rich virtual reality to be inhabited. In this view, that of the Class One player, the parser exists only as a conduit for her to inject her choices into that world, just as a Class One reader views the text as a window — hopefully as transparent as possible — through which she views the action in the storyworld. This has always been my basic approach to IF as a player and a writer. Since I seem to be indulging in a lot of direct quoting in this post anyway, let me get a bit pretentious and quote an earlier version of myself. I wrote the following as a comment on Mike Rubin’s blog back in 2008:

I think many people, myself included, did indeed play Facade as a comedy, trying ever more outrageous actions to see what happens, and, indeed, at some level trying to “break” the system. I would say, though, that when a player begins to do this it’s a sign that the game designer has failed at some level. I began to play Facade for laughs after trying several reasonable approaches and having the game respond either not at all or in a way that was clearly inappropriate to my actions. The mimesis broke down for me then and I began to treat the system as a clever toy rather than an immersive interactive narrative. There’s no shame in Facade’s failure, of course. It’s a revolutionary conception, and bound to need many more iterations before even approaching complete believability.

This does raise a point, though: I don’t think games can maintain their mimesis by scolding the player, telling her in no uncertain terms that she shalt NOT when she attempts to eat her sword or hit her friends. Rather, we should strive to make our writing so good and our environments so believable and our interactions so smooth that our player is drawn into our story, and it never occurs to her to eat her sword or hit her friends, any more than it would to her avatar. In other words, we must enable her to truly BECOME her avatar for the little while she plays.

As soon as the game starts to break down, so to speak, for the player… that’s when she remembers it’s just a silly text adventure, and that’s when she starts playing it for laughs and trying to break the system even further. I do it every year with at least a dozen of the Comp games, PURLOINING doors and buildings and generally running amok through the storyworld. Entertainment is where you find it, after all.

Some players will of course come to every game determined to break it. Some might find IF in general more interesting as a system to be played with than as a story, although I think other genres of gaming would scratch this particular itch much better. To those players, I say, fine, have your fun. However, I think most people who play IF do come to it wanting to be immersed and to experience a storyworld and, yes, a coherent story through someone else’s eyes for a while. The rewards of that must be far greater than those of trying random actions to see where the boundaries of the simulation are (entertaining as that can be).

(Did we say something about not making value judgements? I forget…)

Still, those folks who marveled at Zork in computer stores were not responding to it as a deep and immersive piece of fiction, nor even as a really sophisticated adventure game. Their awe was all bestowed at the level of the parser itself, as an object — a toy — unto itself. For all of the space restrictions they were laboring under, Infocom reserved room for witty rejoinders to the sort of crazy or nonsensical inputs people might walk up and enter in a computer store.

WEST OF HOUSE
YOU ARE STANDING IN AN OPEN FIELD WEST
OF A WHITE HOUSE, WITH A BOARDED FRONT
DOOR.
THERE IS A SMALL MAILBOX HERE.
>FUCK
SUCH LANGUAGE IN A HIGH-CLASS
ESTABLISHMENT LIKE THIS!
>SHIT
YOU OUGHT TO BE ASHAMED OF YOURSELF.
>TAKE ME
HOW ROMANTIC!
>ZORK
AT YOUR SERVICE!
>XYZZY
A HOLLOW VOICE SAYS 'CRETIN'.
>FIND HOUSE
IT'S RIGHT IN FRONT OF YOU. ARE YOU
BLIND OR SOMETHING?
>FIND HANDS
WITHIN SIX FEET OF YOUR HEAD, ASSUMING
YOU HAVEN'T LEFT THAT SOMEWHERE.
>FIND ME
YOU'RE AROUND HERE SOMEWHERE...
>CHOMP
I DON'T KNOW HOW TO DO THAT. I WIN IN
ALL CASES!
>WIN
NATURALLY!
>SIGH
YOU'LL HAVE TO SPEAK UP IF YOU EXPECT ME
TO HEAR YOU!
>REPENT
IT COULD VERY WELL BE TOO LATE!
>WHAT IS A GRUE?
THE GRUE IS A SINISTER, LURKING PRESENCE
IN THE DARK PLACES OF THE EARTH. ITS
FAVORITE DIET IS ADVENTURERS, BUT ITS
INSATIABLE APPETITE IS TEMPERED BY ITS
FEAR OF LIGHT. NO GRUE HAS EVER BEEN
SEEN BY THE LIGHT OF DAY, AND FEW HAVE
SURVIVED ITS FEARSOME JAWS TO TELL THE
TALE.
>WHAT IS A ZORKMID?
THE ZORKMID IS THE UNIT OF CURRENCY OF
THE GREAT UNDERGROUND EMPIRE.
>YELL
AAAARRRRGGGGHHHH!


This is playing Zork as Eliza: seeing what response this or that input gives, and of course probing for the limits. As some recent experiments have demonstrated, this mode of interaction is still pretty much the default when the uninitiated are confronted with a work of IF for the first time. Back in 1981, when computers were not so well understood and for most people still seemed vaguely magical (if not sinister), the idea of typing something, especially something off the subject or just plain inappropriate, and being understood was a much more powerful one, bringing to mind HAL and the Enterprise‘s talking computer.

All of which is apropos of… what? I’m not sure there are any grand lessons to take away here. After a pretty short while, toying with the parser and trying to break things loses its appeal, and the player either starts to engage with the storyworld and its fiction or just goes on to something else; thus the impatience I express above with players who just can’t seem to get past their triumph that, yes, they can break the parser and probably even the world simulation without too much effort. Over a decade after Zork, a graphical adventure called Myst became for some years the bestselling computer game of all time. It was often labeled the least-played bestseller ever. People bought it to show off their new graphics cards, sound cards, and CD-ROM drives in the midst of the “multimedia PC” boom of the early 1990s, but I’d be shocked if even ten percent seriously engaged with its intellectually intricate puzzles or made a real effort to finish it. Similarly, I suspect that plenty of copies of Zork existed more as something to pull out at cocktail parties than an abiding passion.

But let’s not start printing our “I appreciate Zork on a much deeper level than you” tee-shirts quite yet, because it’s also true that none of us ever wholly become Class One players. One more Get Lamp quote, this time from Bob Bates, captures some of the back and forth that forms a big part of the delights of the text adventure:

“A lot of games only program the ‘if,’ which is that main path I was talking about earlier. If the player does this and everything’s right, then you do this and the game goes on. But there’s always that ‘else.’ What if the player doesn’t do what you expected? What if he comes up with this weird idea or that strange input or that other, off-the-wall thing that he wants to try, just to see if the game breaks. Just to see where the edges are. That’s part of the fun of playing a text adventure, and that’s part of the fun — a great deal of the fun — that I had in creating them, in that imagined dialog with the player, so that at the end of the day when the player does this very weird thing, and he says, ‘Oh, nobody would ever think of trying this,’ he says, ‘Oh, my goodness! There’s a non-default response there! The author actually thought about that!’ That helps form that bond between you and the author. ‘That guy’s just as strange as I am. He and I think the same way.'”

So, a motto for text-adventure success: attract and charm them with your parser, retain them with your storyworld. In the spirit of the latter, we’ll put our Class One players’ hats on and venture into the Great Underground Empire next time. No, really, this time I promise.

When we left off last time, Marc Blank and Joel Berez were considering how to bring Zork to the microcomputer. Really, they were trying to solve three interrelated problems. At the risk of being pedantic, let me lay them out for you:

1. How to get Zork, a massive game that consumed 1 MB of memory on the PDP-10, onto their chosen minimum microcomputer system, an Apple II or TRS-80 with 32 K of RAM and a single floppy-disk drive.

2. How to do so in a portable way that would make it as painless as possible to move Zork not only to the Apple II and TRS-80 but also, if all went well, to many more current and future mutually incompatible platforms.

3. How to use the existing MDL source code to Zork as the basis for the new microcomputer version, rather than having to start all over again and implement the game from scratch in some new environment.

If you like, you can see the above as a ranking of the problems in order of importance, from “absolutely, obviously essential” to “would be really nice.” That’s not strictly necessary, though, because, as we’re about to see, Blank and Berez, with the eventual help of the others, actually solved them all pretty brilliantly. I wish I could neatly deal with each item above one at a time, but, as anyone who’s ever tackled a complicated programming task knows, solutions tend to get tangled up with one another pretty quickly. So instead I’ll have to just ask you to keep those three goals in mind as I explain how Blank and Berez’s design worked as a whole.

When faced with a game that is just too large to fit into a new environment, the most obvious solution is simply to make the game smaller — to remove content. That’s one of the things Infocom did with Zork. Stu Galley:

Dave examined his complete map of Zork and drew a boundary around a portion that included about 100 or so locations: everything “above ground” and a large section surrounding the Round Room. The object was to create a smaller Zork that would fit within the constraints established by the design of Joel and Marc. Whatever wouldn’t fit was to be saved for another game, another day.

By cutting Zork‘s world almost in half, Infocom were able to dramatically reduce the size of the game. 191 rooms became 110; 211 items became 117; 911 parseable words became 617. It wasn’t a complete solution to their problems, but it certainly helped, and still left them with a huge game, about the same size as the original Adventure in numbers of rooms but dwarfing it in terms of items and words, and easily bigger than any other microcomputer adventure game. And, as Galley notes above, it left them with plenty of raw material out of which to build a possible sequel.

There were more potential savings to be had by looking at the MDL compiler. As a language designed to perform many general-purpose computing tasks, many of MDL’s capabilities naturally went unused by an adventure game like Zork. Even unused, however, they consumed precious memory. Infocom therefore took a pair of pruning shears to MDL just as they had to Zork itself, cutting away extraneous syntax and libraries, and retaining only what was necessary for implementing an adventure game. They named the new language ZIL, for Zork Implementation Language; the compiler that enabled the language, which still ran only on the PDP-10, they called Zilch. ZIL remained similar enough to MDL in syntax and approach that porting the old MDL Zork to ZIL was fairly painless, yet the new language not only produced tighter, faster executables but was much cleaner syntactically. In fact, ZIL encouraged Infocom to not just port Zork to the new language but to improve it in some ways; the parser, in particular, became even better when implemented in the more sympathetic ZIL.

Here is Zork‘s lantern in MDL:

<OBJECT ["LAMP" "LANTE" "LIGHT"]
	["BRASS"]
	"lamp"
	<+ ,OVISON ,TAKEBIT ,LIGHTBIT>
	LANTERN
	()
	(ODESCO "A battery-powered brass lantern is on the trophy case."
	 ODESC1 "There is a brass lantern (battery-powered) here."
	 OSIZE 15
	 OLINT [0 >])>

And here’s the same item in ZIL:

<OBJECT LANTERN 
           (LOC LIVING-ROOM) 
           (SYNONYM LAMP LANTERN LIGHT) 
           (ADJECTIVE BRASS) 
           (DESC "brass lantern") 
           (FLAGS TAKEBIT LIGHTBIT) 
           (ACTION LANTERN-F) 
           (FDESC "A battery-powered lantern is on the trophy 
             case.") 
           (LDESC "There is a brass lantern (battery-powered) 
             here.") 
           (SIZE 15)>

Just for the record, I’ll give a quick explanation of the ZIL code shown above for those interested. The first line simply tells us that what follows will describe an item — or, in ZIL terminology, “object” — called “lantern.” The next line tells us it is in the living room of the white house. Then we see that it can be referred to by the player as “lamp,” “lantern,” or “light,” with the optional adjective “brass” (which might come in handy to distinguish it from the broken lantern found in another part of the game). The so-called short description — more properly the name under which it shows up in inventory listings and other places where it must be plugged into the text — is “brass lantern.” The TAKEBIT flag means that it is an item the player can pick up and carry around with her; the LIGHTBIT means that it casts light, illuminating any dark room in which it is placed or carried. LANTERN-F is the special action routine for the lantern, a bit of code that allows us to write special “rules” for the lantern that apply only to it, such as routines to allow the player to turn it off and on; as I discussed earlier, this level of programmability and the associated object-oriented approach really make MDL, and by extension ZIL, stand out from other adventure-game development systems of their era. The FDESC is the description of the lantern that appears before it has been moved, as part of the room description for the living room; the LDESC appears after it has been moved and set down somewhere else. Finally, the SIZE determines the size and weight of the lantern for purposes of deciding how much the player can carry with her at one time. The rather messier MDL source I’ll leave as an exercise for you to translate…

So, at this point Infocom have largely addressed problem #3, and at least come a long way with problem #1. That left them still with problem #2. You might think it would be easy enough to design an adventure-engine / database partnership like that Scott Adams came up with. However, this was problematic. Remember that one of the things that made Zork‘s development environment, whether it be MDL or ZIL, so unique was its programmability. To go to a solution like that of Adams would force them to sacrifice that, and ZIL in the process. For ZIL to work, it needed to be able to run code to handle those special interactions like turning the lamp on or off; it needed, in other words, to be a proper, Turing-complete programming language, not just a data-entry system. But how to do that while also having a system that was portable from machine to (incompatible) machine? The answer: they would design a virtual machine, an imaginary computer optimized just for playing text adventures in the same way that ZIL was for coding them, then code an interpreter to simulate that computer on each platform for which they decided to release Zork.

Virtual machines are everywhere today. The apps you run on your Android smartphone actually run inside a virtual machine. You might use something like VMWare on your desktop machine to let you run Linux inside Windows, or vice versa. Big mainframe installations and, increasingly, high-end servers running operating systems like Linux often run in virtual machines abstracted from the underlying hardware, which amongst other benefits lets one carve one giant mainframe up into a number of smaller mainframes. Scenarios like that aside, virtual machines are so appealing for essentially two reasons; virtually (ha!) everyone who decides to employ one does so for one or the other, or, often, both. First, they are much more secure. If malicious code such as a virus gets introduced into a virtual machine, it is contained there rather than infecting the host system, and code that crashes the virtual machine — whether it does so intentionally or accidentally — crashes only the virtual machine, not the host system as a whole. Second, a virtual machine allows one to run the same program on otherwise incompatible devices. It is “write once, run everywhere,” as Java zealots used to say. In their case, each target platform need only have a current implementation of the Java virtual machine (not necessarily the language; just the virtual machine). Virtual machines do also have one big disadvantage: because the host platform is emulating another computer, they tend to be much, much slower than native code run on the same platform. (Yes, technologies like just-in-time compilation can do a lot to alleviate this, but let’s not get any further afield.) Still, computing power is cheap and ubiquitous these days, so this generally doesn’t present such a problem. In fact, the modern situation can get kind of ridiculous; my Kindle version of The King of Shreds and Patches is actually built from one virtual machine (Glulx) running inside another virtual machine (the Java virtual machine), all running on a tiny handheld e-reader — and performance is still acceptable.

Even in 1979 the virtual machine was not a new idea. Between 1965 and 1967, a team at IBM had worked in close partnership with MIT’s Lincoln Laboratory to create an operating system called CP-40, under which up to 14 users were each able to log into their own, single-user computer — simulated entirely in software running on a big IBM mainframe. CP-40 eventually became the basis of the appropriately named VM operating system, first released by IBM in 1972 and still widely used on mainframes today. In 1978, a Pascal implementation known as UCSD Pascal introduced the P-Machine, a portable virtual machine that allowed programs written in UCSD Pascal to run on many disparate machines, including even the Apple II following the release of Apple Pascal in August of 1979. The P-Machine became a major influence on Infocom’s own virtual machine, the Z-Machine.

In opting for a virtual machine they would of course have to pay the performance penalty all virtual machines exact, but this wouldn’t be quite as big as you might expect. Just as they had optimized ZIL, Blank and Berez made the Z-Machine as light and efficient as they possibly could, including only those features really useful for running adventure games. They would implement each platform’s interpreter entirely in highly optimized assembly language, with the result that Zork would, even running inside a virtual machine, still run much, much faster than the BASIC adventures that were common at the time. Anyway, the processing powers of the micros, limited as they were, had never been their real concern in getting Zork onto them — memory was the bottleneck. Yes, they would have to sacrifice some additional memory for the interpreter, but they could save even more by building efficiencies into the Z-Machine. For instance, a special encoding scheme allowed them to store most characters in 5 rather than 8 bits, and to replace the most commonly used words with abbreviations in the code. Such text compression was very significant considering that text is, after all, most of what makes up a text adventure. With such compression techniques, along with all of the slicing and dicing of the game itself and the ZIL language, they ended up with a final game just 77 K in size, not counting of course the virtual-machine interpreter needed to run it; this latter Infocom called Zip (not to be confused with the file-compression format). The 77 K game file itself, which Infocom took to calling the “story file,” is essentially a snapshot of the virtual machine’s memory in its opening state.

When we talk about the storage capacity of a computer, we’re really talking about (much to the confusion of parents and grandparents everywhere) two separate figures: disk capacity and memory (RAM) capacity. An Apple II could store 140 K on a single floppy disk, while the TRS-80 actually did a bit better, managing 180 K. Thus, Infocom now had a game that could fit quite comfortably along with the necessary interpreter on a single disk. RAM was the problem: even if we forget about the necessary interpreter, 77 K just doesn’t go into 32 K, no matter how much you try to force it. Or does it?

It was not unheard of even at this time to use the disk as a sort of secondary memory, reading bits and pieces of data from there into RAM and then discarding them when no longer needed. Microsoft had used just this technique to fit Adventure into the 32 K TRS-80; each bit of text, all stored in a file external to the game itself as per Crowther and Woods’s original design, was read in from disk only when it needed to be printed. However, Infocom’s more sophisticated object-oriented system necessarily intermingled its text with its code, making such a segregated approach impractical. Blank and Berez therefore went a step further: having already designed a virtual machine, they now added an implementation of virtual memory to accompany it.

The concept of virtual memory was also then not a new one in the general world of computer science. In fact, virtual memory dates back even further than the virtual machine, to an early supercomputer developed at the University of Manchester called the Atlas, officially commissioned in 1962. In a virtual-memory system, each program does not have an “honest” view of the host computer’s physical memory. It rather is given a sort of idealized memory map to play with, which may have little to do with the real layout of its host computer’s physical RAM. When it reads from and writes to pieces of this map, the host automatically translates the virtual addresses into real addresses inside its physical memory, transparently. Why bother with such a thing, especially as it necessarily adds processing overhead? Once again, for two main reasons, both of which are usually taken as applicable to a multitasking operating system only, something that was little more than a dream for a microcomputer of 1979 or 1980. First, by effectively sandboxing each program’s memory from every other program’s memory, as well as that being used by the operating system itself, virtual memory assures that a program cannot, out of malice or simple bugginess, go rogue and trash other programs or even bring down the whole system. Second, it gives a computer a fallback position of sorts — an alternative to outright failure — should the program(s) running on it ask for more physical memory than it actually has to give. When that happens, the operating system looks through its memory to find pieces that aren’t being used very often. It then caches these away on disk, making room in physical RAM to allocate the new request. When cached areas are accessed again, they must of course be read back into RAM, possibly being swapped with other chunks if memory is still scarce. All of this happens transparently to the program(s) in question, which continue to live within their idealized view of memory, blissfully unaware of the huffing and puffing the underlying system is doing to keep everything going. Virtual memory has been with us for many years now in the desktop PC world. Of course, there inevitably comes a point of diminishing returns with such a scheme; if you’ve ever opened lots and lots of windows or programs on an older PC and seen everything get really, really slow while the hard disk grinds like a saw mill, now you know what was going on (assuming you didn’t already know, of course; we assume no default level of technical knowledge here at Digital Antiquaria Central).

For the Z-Machine, Berez and Blank employed a much simpler version of virtual memory than you’ll find in the likes of Windows, Linux, or OS X. While such important dynamic information as the current position of the items in the game world must of course always be tracked and updated dynamically, most of the data that makes up a game like Zork is static, unchanging: lots and lots of text, of course, along with lots of program code. Berez and Blank were able to design the ZIL compiler in such a way that it placed all of the stuff that could conceivably change, which we’ll called the dynamic data, first in the story file. Everything else, which we’ll call the static data, came afterward. As it turned out, the 77 K Zork story file contained only 18 K of dynamic data. So, here’s what they did…

The dynamic data — memory the virtual machine will write to as well as read — is always stored in the host computer’s RAM. The static data, however, is loaded in and out of RAM by the interpreter as needed in 1 K blocks known as pages. Put another way: from the perspective of the game program, it has fully 77 K of memory to work with. The interpreter, meanwhile, is frantically swapping blocks of memory in and out of the much more limited physical RAM to maintain this illusion. Like the virtual machine itself, this virtual-memory scheme obviously brings with it a speed penalty, but needs must. On a 32 K system with 18 K reserved for dynamic data, Infocom still had 14 K left over to host the VM interpreter itself, a small stack (an area where programs store temporary information needed for moment-to-moment processing), and a page or two of virtual memory. Sure, it was a bit sluggish at times, but it worked. And, when run on a system with, say, 48 K, the interpreter could automatically detect and use this additional memory to keep more static data in physical RAM, thus speeding things along and rewarding the user for her hardware investment.

With the ZIL / Z-Machine scheme as a whole, Infocom had created a robust, reusable system that could have life far beyond this one-time task of squeezing Zork onto the TRS-80 and Apple II. I trust I’m not spoiling anything if I reveal that that’s exactly what happened.

With this technical foundation, we’ll look next time at the process of actually getting Zork onto the market.

As the Dynamic Modeling Group put the final touches on Zork and put it to bed at last, it was beginning to feel like the end of an era at MIT. Marc Blank was about to graduate medical school and begin his residency in Pittsburgh, which would make extensive MIT hacking impossible even given his seemingly superhuman capacities. Others were finishing their own degree programs at MIT, or just running out of justifications for forestalling “real” careers with real salaries by hanging around their alma mater. In fact, a generational exodus was beginning, not just from the DMG but from MIT’s Laboratory for Computer and AI Lab in general as well. Pressures from the outside world were intruding on the hacker utopia inside MIT at last, pressures which in the next few years would change it forever. Much of the change stemmed from the invention of the microcomputer.

Most in established institutional hacking environments like MIT were initially nonplussed by what’s come to be called the PC revolution. That’s not so surprising, really. Those early microcomputers were absurdly limited machines. The homebrew hackers who bought (and often built) them were just excited to have unfettered access to something that, however minimally, met the definition of “computer.” Those privileged to find a place at an institution like MIT, however, not only had unfettered or nearly unfettered access to the systems there, but said systems were powerful enough to really do something. What charms did an Altair or even TRS-80 have to compare with sophisticated operating systems like TOPS-10 or TOPS-20 or ITS, with well-structured programming languages like LISP and MDL, with research into AI and natural-language processing, even with networked games like Maze and Trivia and, yes, Zork? The microcomputer world looked like a hopelessly uncultured and untutored one, bereft of a whole hacking tradition stretching back two decades or more. How could anyone try to build complex software using BASIC? When many institutional hackers deigned to notice the new machines at all, it was with withering contempt; Stu Galley called “We hate micros!” the unofficial motto of the DMG. They regarded the micros as little more than toys — the very same reaction as most of the general population.

By the spring of 1979, though, it was becoming increasingly clear to anyone willing to look that the little machines had their uses. WordStar, the first really usable microcomputer word processor, had been out for a year, and was moving more and more CP/M-based machines into offices and even writer’s studies. At the West Coast Computer Faire that May, Dan Bricklin demonstrated for the first time VisiCalc, the world’s first spreadsheet program, which would revolutionize accounting and business-planning practice. “How did you ever do without it?” asked the first pre-release advertisement, hyperbolically but, as it turned out, presciently; a few years later millions would be asking themselves just that question. Unlike WordStar and even Scott Adams’s Adventureland, VisiCalc was not a more limited version of an institutional computing concept implemented on microcomputer hardware. It had been conceived, designed, and implemented entirely on the Apple II, the first genuinely new idea in software to be born on the microcomputer — and a sign of a burgeoning changing of the guard.

The microcomputer brought many, many more users to computers than had ever existed before. That in turn brought more private-industry investment into the field, driven by a new reality: that you could make real money at this stuff. And that knowledge brought big changes to MIT and other institutions of “pure” hacking. Most (in)famously, the AI Lab was riven that winter and spring of 1979 by a dispute between Richard Greenblatt, pretty much the dean of the traditional hacker ethic at MIT, and a more pragmatic administrator named Russell Noftsker. Along with a small team of other hackers and hardware engineers, Greenblatt had developed a small single-user computer — a sort of boutique micro, the first of what would come to be called “workstations” — optimized for running LISP. Believing the design to have real commercial potential, Noftsker approached Greenblatt with a proposal to form a company and manufacture it. Greenblatt initially agreed, but soon proved (at least in Noftsker’s view) unwilling to sacrifice even the most minute hacker principle in the face of business realities. The two split in an ugly way, with Noftsker taking much of the AI Lab with him to implement Greenblatt’s original concept as Symbolics, Inc. Feeling disillusioned and betrayed, Greenblatt eventually left as well to form his own, less successful company, Lisp Machines.

It’s not as if no one had ever founded a company out of MIT before, nor that commerce had never mixed with the idealism of the hackers there. The founders of DEC itself, Ken Olson and Harlan Anderson, were MIT alumni who had done the basic design for what became DEC’s first machine, the PDP-1, as students there in the mid-1950s. Thereafter, MIT maintained always a cozy relationship with DEC, testing hardware and, most significantly, developing much essential software for the company’s machines — a relationship that was either, depending on how you look at it, a goldmine for the hackers in giving them perpetual access to the latest technology or a brilliant scheme by DEC for utilizing some of the best computing minds of their generation without paying them a dime. Still, what was happening at MIT in 1979 felt qualitatively different. These hackers were almost all software programmers, after all, and the microcomputer market was demonstrating that it was now possible to sell software on its own as prepackaged works, the way you might a record or a book. As a wise man once said, “Money changes everything.” Many MIT hackers were excited by the potential lucre, as evidenced by the fact that many more chose to follow Noftsker than the idealistic Greenblatt out of the university. Only a handful, such as Marvin Minsky and the ever-stubborn Richard Stallman, remained behind and continued to hew relentlessly to the old hacker ethic.

Infocom’s founders were not among the diehards. As shown by their willingness to add (gasp!) security to ITS to protect their Zork source, something that would have drawn howls of protest from Stallman on at least two different levels, their devotion to the hacker ethic of total sharing and transparency was negotiable at best. In fact, Al Vezza and the DMG had been mulling over commercial applications for the group’s creations as far back as 1976. As the 1979 spring semester wrapped up, however, it seemed clear that if this version of the DMG, about to be scattered to the proverbial winds as it was, wanted to do something commercially, the time to get started was now. And quite a lot of others at MIT were doing the same thing, weren’t they? It wouldn’t do to be left behind in an empty lab, as quite literally happened to poor old Richard Stallman. That’s how Al Vezza saw the situation, anyway, and his charges, eager to remain connected and not averse to increasing their modest university salaries, quickly agreed.

And so Infocom was officially founded on June 22, 1979, with ten stockholders. Included were three of the four hackers who had worked on Zork: Tim Anderson, Dave Lebling, and the newly minted Dr. Marc Blank (commuting from his new medical residency in Pittsburgh). There were also five other current or former DMG hackers: Mike Broos, Scott Cutler, Stu Galley, Joel Berez, Chris Reeve. And then there was Vezza himself and even Licklider, who agreed to join in the same sort of advisory role he had filled for the DMG back at MIT. Each person kicked in whatever funding he could afford, ranging from $400 to $2000, and received an appropriate percentage of the new company’s stock in return. Total startup funds amounted to $11,500. The name was necessarily nondescript, considering that no one knew quite what (if anything) the company would eventually do. The fractured, futuristic compound was much in vogue amongst technology companies of the time — Microsoft, CompuWare, EduWare — and Infocom just followed the trend in choosing the name “least objectionable to everyone.”

As should be clear from the above, Infocom did not exactly begin under auspicious circumstances. I’d call them a garage startup, except that they didn’t even have a garage. Infocom would exist for some months as more of a theoretical company in limbo than an actual business entity. It didn’t even get its first proper mailing address — a P.O. Box — until March of 1980. Needless to say, no one was quitting their day jobs as they met from time to time over the following months to talk about what ought to come next. In August, Mike Broos had already gotten bored with the endeavor and quit, leaving just nine partners. Everyone agreed that they needed something they could put together relatively quickly to sell and really get the company off the ground. More ambitious projects could then follow. But what could they do for that first project?

The hackers trolled through their old projects from MIT, looking for ideas. They kept coming back to the games. There was that Trivia game, but it wouldn’t be practical to store enough questions on a floppy disk to make it worthwhile. More intriguing was the Maze game. Stand-up arcades were booming at the time. If Infocom could build a version of Maze for arcades, they would have something unprecedented. Unfortunately, getting there would require a huge, expensive hardware- as well as software-engineering project. The Infocom partners were clever enough, but they were all software rather than hardware hackers, and money was in short supply. And then of course there was Zork… but there was no way to squeeze a 1 MB adventure game into a 32 K or 48 K microcomputer. Anyway, Vezza wasn’t really comfortable with getting into the games business on any terms, fearing it could tarnish the company’s brand even if only used to raise some early funds and bootstrap the startup. So there was also plenty of discussion of other, more business-like ideas also drawn from the DMG’s project history: a document-tracking system, an email system, a text-processing system.

Meanwhile, Blank was living in Pittsburgh and feeling rather unhappy at being cut off from his old hacking days at MIT. Luckily, he did have at least one old MIT connection there. Joel Berez had worked with the DMG before graduating in 1977. He had spent the last two years living in Pittsburgh and working for his family’s business (which experience perhaps influenced the others to elect him as Infocom’s President in November of 1979). Blank and Berez made a habit of getting together for Chinese food (always the hacker’s staple) and talking about the old times. These conversations kept coming back to Zork. Was it really impossible to even imagine getting the game onto a microcomputer? Soon the conversations turned from nostalgic to technical. As they began to discuss technical realities, other challenges beyond even that of sheer computing capacity presented themselves.

Even if they could somehow get Zork onto a microcomputer, which microcomputer should they choose? The TRS-80 was by far the best early seller, but the Apple II, the Cadillac of the trinity of 1977, was beginning to come on strong now, aided by the new II Plus model and VisiCalc. Next year, and the year after that… who knew? And all of these machines were hopelessly incompatible with one another, meaning that reaching multiple platforms must seemingly entail re-implementing Zork — and any future adventure games they might decide to create — from scratch on each. Blank and Berez cast about for some high-level language that might be relatively portable and acceptable for implementing a new Zork, but they didn’t find much. BASIC was, well, BASIC, and not even all that consistent from microcomputer to microcomputer. There was a promising new implementation of the more palatable Pascal for the Apple II on the horizon, but no word of a similar system on other platforms.

So, if they wanted to be able to sell their game to the whole microcomputer market rather than just a slice of it, they would need to come up with some sort of portable data design that could be made to work on many different microcomputers via an interpreter custom-coded for each model. Creating each interpreter would be a task in itself, of course, but at least a more modest one, and if Infocom should decide to do more games after Zork the labor savings would begin to become very significant indeed. In reaching this conclusion, they followed a line of reasoning already well-trod by Scott Adams and Automated Simulations.

But then there was still another problem: Zork currently existed only as MDL source, a language which of course had no implementation on any microcomputer. If they didn’t want to rewrite the entire game from scratch — and wasn’t the point of this whole exercise to come up with a product relatively quickly and easily? — they would have to find a way to make that code run on microcomputers.

They had, then, quite a collection of problems. We’ll talk about how they solved every one of them — and pretty brilliantly at that — next time.