RSS

Monthly Archives: January 2012

Exploring Zork, Part 2

Today we’ll tackle the meat of Zork‘s Great Underground Empire, shown on the map below.

Exploring south from the cellar where we left off yields our second treasure and our first way out of the underground; we can carry exactly two items out with us via the fireplace in the living room of the white house. (But we can’t go back down that way; “ONLY SANTA CLAUS CLIMBS DOWN CHIMNEYS,” the game tells us, in a classic bit of adventure-game logic.) As we explore we’ll continue to find more and more — and more and more convenient — means of ingress and egress. Eventually, even the unknown nasty who keeps closing and barring the trapdoor behind us will stop it.

We also find a second note — oops, an “OWNER’s MANUAL” — south of the cellar. It conveys some of the wonder of this little, functioning world Infocom have constructed.

>EXAMINE PAPER

CONGRATULATIONS!
YOU ARE THE PRIVILEGED OWNER OF A
GENUINE ZORK GREAT UNDERGROUND EMPIRE
(PART I), A SELF CONTAINED AND SELF
MAINTAINING UNIVERSE. IF USED AND
MAINTAINED IN ACCORDANCE WITH NORMAL
OPERATING PRACTICES FOR SMALL UNIVERSES,
ZORK WILL PROVIDE MANY MONTHS OF
TROUBLE-FREE OPERATION. PLEASE CHECK
WITH YOUR DEALER FOR PART II AND OTHER
ALTERNATE UNIVERSES.

Like the title page shown in my previous post, the note also shows that Infocom were also already planning at least a Zork 2 at this stage, even if their naming rubric could still use some work. More interestingly, it also shows that they were already envisioning parlaying ZIL and the Z-Machine into a whole line of other, original games. In including an advertisement for other games within this one, Infocom were following the lead of Scott Adams, who always seemed to find space to plug one or two other current or upcoming games even within his tiny 16 K creations.

When we proceed north from the cellar, we run into a sort of perfect storm of bad luck.

>N
THE TROLL ROOM
THIS IS A SMALL ROOM WITH PASSAGES TO
THE EAST AND SOUTH AND A FORBIDDING HOLE
LEADING WEST. BLOODSTAINS AND DEEP
SCRATCHES (PERHAPS MADE BY AN AXE) MAR
THE WALLS.
A NASTY-LOOKING TROLL, BRANDISHING A
BLOODY AXE, BLOCKS ALL PASSAGES OUT OF
THE ROOM.
A SEEDY-LOOKING INDIVIDUAL WITH A LARGE
BAG JUST WANDERED THROUGH THE ROOM. ON
THE WAY THROUGH, HE QUIETLY ABSTRACTED
ALL VALUABLES FROM THE ROOM AND FROM
YOUR POSSESSION, MUMBLING SOMETHING
ABOUT "DOING UNTO OTHERS BEFORE.."
THE TROLL'S MIGHTY BLOW DROPS YOU TO
YOUR KNEES.
THE THIEF SLOWLY APPROACHES, STRIKES
LIKE A SNAKE, AND LEAVES YOU WOUNDED.
>KILL TROLL WITH SWORD
I CAN'T SEE ANY SWORD HERE.
>KILL TROLL WITH KNIFE
A GOOD STROKE, BUT IT'S TOO SLOW, THE
TROLL DODGES.
THE TROLL'S AXE REMOVES YOUR HEAD.
IT APPEARS THAT THAT LAST BLOW WAS TOO
MUCH FOR YOU. I'M AFRAID YOU ARE DEAD.

**** YOU HAVE DIED ****

What’s happened here is that we’ve simultaneously met two of the other inhabitants of the underground, the troll and the thief. The former stays in place, but the latter is Zork‘s response to the pirate and the dwarfs of Adventure, a classic Dungeons and Dragons-style “wandering monster.” He roams throughout the underground, and not only takes the occasional poke at us with his stiletto, but — worse — picks up items we might have left here or there for safekeeping and scatters them randomly about. Even worse, he takes treasures for himself, hiding them away (more on that later). And worst of all, he’s happy to steal things off our own person. Woe to the adventurer whom he leaves in the dark without a lamp! In this case, he steals our sword just as we kind of need it to fight him and the troll and all, leaving us with only the much less effective knife. The end result is predictable.

The credit (or blame) for the combat engine belongs to Lebling:

Dave, an old Dungeons and Dragons player, didn’t like the completely predictable ways of killing creatures off. In the original game, for example, one killed a troll by throwing a knife at him; he would catch the knife and gleefully eat it (like anything else you threw at him), but hemorrhage as a result. Dave added basically the full complexity of DD-style fighting, with different strengths for different weapons, wounds, unconsciousness, and death. Each creature had its own set of messages, so a fight with the thief (who uses a stiletto) would be very different from a fight with the troll and his axe.

The danger of all this dynamism and emergent behavior is that it can lead to exactly the sort of thing that just happened to us, where the player is killed capriciously, without ever really having a chance. Eamon players never seemed to mind that sort of thing, but it didn’t sit well with Infocom. They would back well away from randomized combat in later games, a bias that the modern interactive fiction community has generally taken to heart. The main sign of this road not taken in the later Infocom canon is the “DIAGNOSE” verb, introduced in Zork to give the player a quick rundown of her current wounds, which persisted in later games as a rather pointless oddity generally yielding a generic response. Notably, “DIAGNOSE” is the only standard verb of the Infocom system that was not adapted by more modern IF languages like Inform and TADS.

Anyway, we restore a time or two, get a bit more lucky with our die rolls, kill the troll and avoid the thief, and move on into the reservoir area and, eventually, Flood Control Dam #3, one of the more memorable Zork landmarks. The relatively sober descriptions of the grand, long abandoned edifice itself are contrasted with the silliness of the guidebook we find inside the lobby.

>EXAMINE GUIDEBOOK
"FLOOD CONTROL DAM #3
FCD#3 WAS CONSTRUCTED IN YEAR 783 OF
THE GREAT UNDERGROUND EMPIRE TO HARNESS
THE MIGHTY FRIGID RIVER. THIS WORK WAS
SUPPORTED BY A GRANT OF 37 MILLION
ZORKMIDS FROM YOUR OMNIPOTENT LOCAL
TYRANT LORD DIMWIT FLATHEAD THE
EXCESSIVE. THIS IMPRESSIVE STRUCTURE IS
COMPOSED OF 370,000 CUBIC FEET OF
CONCRETE, IS 256 FEET TALL AT THE
CENTER, AND 193 FEET WIDE AT THE TOP.
THE LAKE CREATED BEHIND THE DAM HAS A
VOLUME OF 1.7 BILLION CUBIC FEET, AN
AREA OF 12 MILLION SQUARE FEET, AND A
SHORE LINE OF 36 THOUSAND FEET.
WE WILL NOW POINT OUT SOME OF THE MORE
INTERESTING FEATURES OF FCD#3 AS WE
CONDUCT YOU ON A GUIDED TOUR OF THE
FACILITIES:
1) YOU START YOUR TOUR HERE IN
THE DAM LOBBY. YOU WILL NOTICE ON
YOUR RIGHT THAT .........

Much of Zork‘s literary character, which comes through quite distinctly despite the relatively limited number of actual words in the game (it’s mostly been the very longest descriptions that I’ve been quoting here), arises from this juxtaposition of melancholic, faded glory and unabashed silliness. I’ll let you decide whether that was a real aesthetic choice or the accidental result of having too many cooks (writers) in the kitchen. In any case, we find another prime example of said silliness in the dam’s maintenance room.

>N
MAINTENANCE ROOM
THIS IS WHAT APPEARS TO HAVE BEEN THE
MAINTENANCE ROOM FOR FLOOD CONTROL DAM
#3. APPARENTLY, THIS ROOM HAS BEEN
RANSACKED RECENTLY, FOR MOST OF THE
VALUABLE EQUIPMENT IS GONE. ON THE WALL
IN FRONT OF YOU IS A GROUP OF BUTTONS,
WHICH ARE LABELLED IN EBCDIC. HOWEVER,
THEY ARE OF DIFFERENT COLORS: BLUE,
YELLOW, BROWN, AND RED. THE DOORS TO
THIS ROOM ARE IN THE WEST AND SOUTH
ENDS.
THERE IS A GROUP OF TOOL CHESTS HERE.
THERE IS A WRENCH HERE.
THERE IS AN OBJECT WHICH LOOKS LIKE A
TUBE OF TOOTHPASTE HERE.
THERE IS A SCREWDRIVER HERE.

The “EBCDIC” reference is a bit of hacker humor that might, depending on your background, require some explanation. During the early 1960s most computer makers agreed on something called ASCII (“American Standard Code for Information Interchange”) as a system for encoding textual characters on computers. Since computers can ultimately understand only numbers, ASCII is essentially a look-up table that the computer can use to know that when it encounters, say, the number 65 in a text file, it should print the character “A” to the screen. A standard was necessary to ensure that computers of different makes and models could easily exchange textual information amongst themselves. Just as everyone had settled on ASCII and thus solved a rather vexing problem, however, IBM suddenly chose to abandon the standard on its mainframes in favor of something called EBCDIC (“Extended Binary-Coded Decimal Interchange Code”). Its reason for doing so, at least according to DEC hackers, was a deliberate effort to make its machines incapable of exchanging data with those from other manufacturers, in the belief that doing so would lock its customers into using only IBM products for absolutely everything. To make things worse, EBCDIC was just a bad system in comparison to ASCII. In ASCII “A” numerically precedes “B” which precedes “C,” etc.; in EBCDIC each letter is assigned a number willy-nilly, with no apparent rhyme or reason. This makes, say, looping through the alphabet, a scenario that comes up quite often in programming, much more difficult than it ought to be. And then there was IBM’s habit of constantly revising EBCDIC, making it even incompatible with itself in its various versions. Still, it persists even today on the big legacy mainframes. Among hackers, EBCDIC came to stand in for any incomprehensible bit of language or jibberish, the hacker equivalent of saying (with apologies to anyone who actually speaks Greek), “It’s Greek to me!” And that, to make a long explanation not much longer, is the reason that the dam’s buttons are labelled in EBCDIC.

We solve a clever puzzle at the dam to adjust the water level on its two sides, thus opening up the river and the northern part of the underground for exploration. Before we do that, though, we’ll have a look at the temple to the southeast. We find there an ivory torch that, in addition to being a treasure, functions as an inexhaustable light source. This bit of mercy is even more appreciated than the extra batteries we can find in Adventure, particularly since using it doesn’t cost us points. We just need to be sure we conserve enough lantern-life to get us through the coal mine, about which more in a moment.

The sceptre, a treasure we find under the temple in the “EGYPTIAN ROOM,” is at the heart of the first really bad puzzle of the game. We are expected to take it to the rainbow outside and wave it to cross and reveal the inevitable pot of gold.

>WAVE SCEPTRE
SUDDENLY, THE RAINBOW APPEARS TO BECOME
SOLID AND, I VENTURE, WALKABLE (I THINK
THE GIVEAWAY WAS THE STAIRS AND
BANNISTER).
>E
ON THE RAINBOW
YOU ARE ON TOP OF A RAINBOW (I BET YOU
NEVER THOUGHT YOU WOULD WALK ON A
RAINBOW), WITH A MAGNIFICENT VIEW OF THE
FALLS. THE RAINBOW TRAVELS EAST-WEST
HERE.

If you’ve played a few adventure games, of course, you fully expected to walk on that rainbow. The question is how you’re supposed to arrive at this particular way of doing it. The one real hint is external to the game: Adventure featured a rod that it was possible to wave to cross a similar (albeit rainbow-less) chasm. Thus we have yet another point where Zork simply seems to assume previous knowledge of Adventure — although even given that knowledge solving this puzzle requires quite an intuitive leap.

After exploring the region beyond the rainbow, we return underground and eventually wind up in… Hades.

>D
ENTRANCE TO HADES
YOU ARE OUTSIDE A LARGE GATEWAY, ON
WHICH IS INSCRIBED
"ABANDON EVERY HOPE, ALL YE WHO
ENTER HERE."
THE GATE IS OPEN; THROUGH IT YOU CAN SEE
A DESOLATION, WITH A PILE OF MANGLED
BODIES IN ONE CORNER. THOUSANDS OF
VOICES, LAMENTING SOME HIDEOUS FATE, CAN
BE HEARD.
THE WAY THROUGH THE GATE IS BARRED BY
EVIL SPIRITS, WHO JEER AT YOUR ATTEMPTS
TO PASS.

Some of the everything-but-the-kitchen-sink feel that characterized the original PDP-10 Zork also comes through here. For all of the original mythology found in Lord Dimwit Flathead, zorkmids, and Flood Control Dam #3, we’ve also got here Hades from Greek mythology with a Dante paraphrase to boot. (Indeed, this feels more like the Christian Hell than the mythological Hades; its chilling tone provides yet another contrast to the more jokey sections.) Soon enough, we’ll also be meeting a nineteenth-century American coal mine and an Odysseus-fearing cyclops. And we’ve already visited (and plundered) the tomb of Ramses II. There’s of course a puzzle to solved in this Hades as well, but I’ll leave that one to you. Afterward, we’ll return to the vicinity of the dam for a trip down the river.

The Frigid River section was the work of Marc Blank, who added it quite early in Zork‘s development. Its key component is the inflatable boat that we must use to navigate it. This implementation of a vehicle arguably marked the first point where Zork‘s makers really showed their willingness to go beyond their inspiration of Adventure by modeling a much more intricate, believable storyworld. It also brought with it some harsh lessons in design. Tim Anderson:

In the original game, there were rooms, objects, and a player; the player always existed in some room. Vehicles were objects that became, in effect, mobile rooms. This required changes in the (always delicate) interactions among verbs, objects, and rooms (we had to have some way of making “walk” do something reasonable when the player was in the boat). In addition, ever-resourceful Zorkers tried to use the boat anywhere they thought they could. The code for the boat itself was not designed to function outside the river section, but nothing kept the player from carrying the deflated boat to the reservoir and trying to sail across. Eventually the boat was allowed in the reservoir, but the general problem always remained: anything that changes the world you’re modelling changes practically everything in the world you’re modelling.

Although Zork was only a month old, it could already surprise its authors. The boat, due to the details of its implementation, turned into a “bag of holding”: players could put practically anything into it and carry it around, even if the weight of the contents far exceeded what a player was allowed to carry. The boat was two separate objects: the “inflated boat” object contained the objects, but the player carried the “deflated boat” object around. We knew nothing about this: someone finally reported it to us as a bug. As far as I know, the bug is still there.

I wasn’t able to reproduce this bug in this early Apple II implementation. More’s the pity; a bag of holding would be nice to have in this game. (Update: Turns out this bug is still there. I just wasn’t clever enough to figure out how to exploit it. See Nathan’s comment below for the details.)

After the Frigid River, which turns out to connect with the Aragain Falls outdoors, we next explore north beyond the reservoir. The coal mine was the result of the other Zork team members specifically asking Bruce Daniels for “a particularly nasty section.” His response originally involved a huge maze similar to the other huge Zork maze which we’ll get to in my next post. The team decided that enough was enough, however, and edited it down to a fairly manageable four rooms. Tim Anderson nevertheless notes this as “a late example of making things hard by making them tedious.” Still, the coal mine we’re left with actually isn’t all that “nasty.” It has some tricky but manageable puzzles, as long as we aren’t stupid enough to carry an open flame — i.e., the torch — inside. One of the outcomes is a diamond. (In another choice Get Lamp interview, David Welbourn notes how every adventure-game coal mine always seems to contain a diamond; would that it were the same in real life.)

Discounting only the maze area to the west, we’ve now completely explored the underground and solved all of its puzzles but one. We still have the “LOUD ROOM” to deal with.

>D
LOUD ROOM
THIS IS A LARGE ROOM WITH A CEILING
WHICH CANNOT BE DETECTED FROM THE
GROUND. THERE IS A NARROW PASSAGE FROM
EAST TO WEST AND A STONE STAIRWAY
LEADING UPWARD. THE ROOM IS DEAFENINGLY
LOUD WITH AN UNDETERMINED RUSHING SOUND.
THE SOUND SEEMS TO REVERBERATE FROM ALL
OF THE WALLS, MAKING IT DIFFICULT EVEN
TO THINK.
ON THE GROUND IS A LARGE PLATINUM BAR.
>GET BAR
BAR BAR ...
>BAR BAR
BAR BAR ...
>GET BAR BAR
BAR BAR ...
>L
L L ...
>LOOK
LOOK LOOK ...

This room feels like something of a throwback to more primitive games whose two-word parsers and limited world models forced them to replace relatively sophisticated environmental puzzles with guess-the-word games. The Zork team had specifically wanted to avoid the pitfalls of the early parsers with their frustrating non-specificity. Blank, speaking of Adventure: “It really bothered us that if you said ‘Take bird’ it would put the bird in the cage for you–sort of doing things behind your back.” All of which makes this puzzle and its solution — “ECHO” — feel like the betrayal of an ideal of sorts.

But its frustrations are nothing compared to the maze, one of the largest and nastiest of its type in adventure-game history. We’ll tackle that monster, and finish up, next time.

 
 

Tags: , ,

Exploring Zork, Part 1

I’ve personally never found detailed accounts of other people’s experiences in videogames all that compelling. Like a Chris Farley interview, they mostly tend to end up as all anecdote and little narrative substance. I’ve therefore shied away from that approach for this blog. I do, however, want to examine Zork in some depth, and in a way that goes beyond just a review. So, I thought I would write these posts as a sort of guided tour of the game. You can just read along and get a pretty good idea of the experience of a player, or if you’re more ambitious you can play along with me. I do spoil some puzzles, but pretty much only the bad ones, so this might even make a nice way to experience the game, pitched somewhere between going it completely alone and just typing from a walkthrough. The approach is inspired by the old Computer Gaming World articles of Scorpia.

Infocom’s took a dedication to quality to extremes almost unheard of amongst game developers of their era. Zork was updated about a dozen separate times between 1980 and 1984, to add polish and/or to fix bugs. When players tackle it today, they naturally tend to end up playing the final, definitive version that is the most widely distributed today. For this project, however, I wanted to see the game the way players originally would have. This playthrough is therefore based on what I believe to be its first release on the Apple II, the platform where it first achieved widespread popularity.

There’s some question as to whether the Zork games should be considered freely distributable or not. Activision, the company that owns the Infocom intellectual property, released them for free some 15 years ago as part of a promotional campaign for the graphic adventure Zork: Grand Inquisitor, but there’s room for debate about whether they really meant that to be a permanent, free forevermore sort of thing or just a limited window of opportunity. Such questions are a bit more than academic because, despite not having done much with the Infocom games in some 15 years, there are signs that Activision still regards them as having some value, unlike other games of their era that I haven’t hesitated to make available on this site. Still, sites like the Infocom Homepage have been hosting the Zork games for years with no apparent repercussions. Because of that, and because I’d really like for anyone who wants to follow along with what follows to have access to the same older version of Zork that I’m using, I’m going to make it available here, as either an Apple II disk image (for the ultimate retro-experience) or a standalone story file you can load into a modern interpreter. Or you can even play it right in your browser.

But not, I’m embarrassed to have to say, my own Filfre. This is what’s known as a version 2 story file, a very early standard that Infocom soon updated to version 3, a standard they stayed with for many games thereafter. Because the early Zorks were quickly replaced by their version 3 counterparts, I never got around to adding support for earlier versions, seeing these as of only historical interest. Ah, the irony bites deep… I really need to get on that. Anyway, Frotz will do you just fine in the meantime, as will plenty of others.

When we first boot Zork on our trusty Apple II, we’re greeted with one of the most famous openings in gaming history, the white house with the mailbox.

You’ll notice that the screenshot above and the transcript excerpts that follow are written in ALL CAPS. The Z-Machine specification supported lower case right from the beginning, but, rather shockingly, the Apple II’s standard display hardware still did not at this stage. (Lower case did not become a standard feature on the Apple II until the release of the IIe in 1983.) Thus the interpreter has to translate the text into capitals for output. I’ve preserved this in the interest of giving the full, authentic experience; I hope it’s not too annoying.

Inside the mailbox is a leaflet.

>READ LEAFLET
WELCOME TO ZORK
ZORK IS A GAME OF ADVENTURE,
DANGER, AND LOW CUNNING. IN IT YOU WILL
EXPLORE SOME OF THE MOST AMAZING
TERRITORY EVER SEEN BY MORTALS.

NO COMPUTER SHOULD BE WITHOUT ONE!

THE ORIGINAL ZORK WAS CREATED BY TIM
ANDERSON, MARC BLANK, BRUCE DANIELS, AND
DAVE LEBLING. IT WAS INSPIRED BY THE
ADVENTURE GAME OF CROWTHER AND WOODS.
THIS VERSION WAS CREATED BY MARC BLANK,
DAVE LEBLING, JOEL BEREZ, AND SCOTT
CUTLER.

(C) COPYRIGHT 1979 & 1980 INFOCOM,
INC. ALL RIGHTS RESERVED.

Interestingly, this specific acknowledgment of the debt Zork owes to Adventure would go away in later releases. But then we don’t need the leaflet to make us aware of that debt. As I stated in a previous post, the similarity of Zork and Adventure, particularly the opening sections of each, is pronounced enough that the former can almost seem a remake of the latter. In Zork the white house (“A BEAUTIFUL COLONIAL”) stands in for Adventure‘s well house, but there’s still plenty of difficult-to-map forest surrounding it.

As we explore, you might want to expand the map above and those that follow in another window to help you to follow along.

In keeping with a general theme of doing Adventure better than Adventure itself, Zork‘s above-ground area does have a bit more of interest to offer. Up a tree we find a jewel-encrusted egg, the first of 19 treasures we will need to collect to win. (Personal Software’s promotional copy, which talked about the “20 treasures of Zork,” didn’t even get this figure right.)

>U
UP A TREE
YOU ARE ABOUT 10 FEET ABOVE THE GROUND
NESTLED AMONG SOME LARGE BRANCHES. THE
NEAREST BRANCH ABOVE YOU IS ABOVE YOUR
REACH.
BESIDE YOU ON THE BRANCH IS A SMALL
BIRD'S NEST.
IN THE BIRD'S NEST IS A LARGE EGG
ENCRUSTED WITH PRECIOUS JEWELS,
APPARENTLY SCAVENGED SOMEWHERE BY A
CHILDLESS SONGBIRD. THE EGG IS COVERED
WITH FINE GOLD INLAY, AND ORNAMENTED IN
LAPIS LAZULI AND MOTHER-OF-PEARL. UNLIKE
MOST EGGS, THIS ONE IS HINGED AND HAS A
DELICATE LOOKING CLASP HOLDING IT
CLOSED. THE EGG APPEARS EXTREMELY
FRAGILE.

The egg is also the key part of one of the cruelest puzzles; more on that much later.

The egg illustrates an aspect of Zork that can be somewhat jarring, even comical. Most of the environment is described very tersely indeed, as was typical in games of this era (“THIS IS A DIMLY LIT FOREST, WITH LARGE TREES ALL AROUND.”) Yet every once in a while, as with the egg shown above, the implementors relax and indulge their literary sensibilities a bit. The effect when playing is surprisingly akin to triggering a cut scene in a modern game. Here’s another of those moments from the outdoors, the “CANYON VIEW.”

CANYON VIEW
YOU ARE AT THE TOP OF THE GREAT CANYON
ON ITS WEST WALL. FROM HERE THERE IS A
MARVELOUS VIEW OF THE CANYON AND PARTS
OF THE FRIGID RIVER UPSTREAM. ACROSS THE
CANYON, THE WALLS OF THE WHITE CLIFFS
JOIN THE MIGHTY RAMPARTS OF THE FLATHEAD
MOUNTAINS TO THE EAST. FOLLOWING THE
CANYON UPSTREAM TO THE NORTH, ARAGAIN
FALLS MAY BE SEEN, COMPLETE WITH
RAINBOW. THE MIGHTY FRIGID RIVER FLOWS
OUT FROM A GREAT DARK CAVERN. TO THE
WEST AND SOUTH CAN BE SEEN AN IMMENSE
FOREST, STRETCHING FOR MILES AROUND. A
PATH LEADS NORTHWEST. IT IS POSSIBLE TO
CLIMB DOWN INTO THE CANYON FROM HERE.

Woods created some of the same effect in Adventure as well, most notably with the “BREATH-TAKING VIEW,” but in Zork these “cut scenes” come much more frequently.

There’s not a whole lot more we can do outside at the moment, so we’ll make our way into the house. Going up into its attic brings what may just be the best remembered Infocom trope of all: the grue.

KITCHEN
>U
IT IS PITCH BLACK. YOU ARE LIKELY TO BE
EATEN BY A GRUE.

“Grue” is tossed out from time as the name of a monster (“man, ocular bat, the unusual hoon”) in the Dying Earth story cycle of fantasy and science-fiction writer Jack Vance. However, it’s never really described as anything more than something the characters apparently find very frightening. Lebling, who like Gary Gygax of Dungeons and Dragons fame was a big fan of Vance, borrowed the name and the general idea of a mysterious creature that haunts the dark as a solution to a design problem. Trying to move around or do much of anything in the dark in Adventure would lead the player to fall into a pit in the cave and die. Lebling wanted the same mechanic in Zork, but had the problem that such a death was not always realistic in that game’s more diverse environment; the attic of the house, for instance, was presumably not riddled with sinkholes like the surface of a cave might be. The grue provided a handy, one-size-fits-all solution for any conceivable dark area. In the first build after the grue was added to the PDP-10 Zork, the U.S. News and Dungeon Report that was always kept in the white house mentioned that Bruce Daniels had spent weeks wandering around the underground filling in all of the pits.

Despite its very practical origins, the idea of a deadly slavering creature that no one has ever actually seen — grues die instantly if exposed to light — was immensely appealing to Infocom as both horror and comedy. There’s an almost mythical quality to the grue, as of the unknown monster that every child is convinced lurks under her bed. Grues make appearances in virtually all of their early games, and still live on today in hacker culture — even if one sometimes wishes they wouldn’t, as most of the grue jokes that crop up when one mentions text adventures in the wrong company were stale 25 years ago. You can decide for yourself whether MC Frontalot’s homage belongs in this category. (Personally, I’m more a fan of “The Pr0n Song.”) One final strange fact: my Firefox spell checker knows “grue,” but doesn’t know “Zork.”

Like Adventure‘s well house, the white house will serve as a de facto staging area for our underground explorations, as well as the place where we collect our treasures. Zork‘s trophy case makes this purpose even more explicit.

>W
LIVING ROOM
YOU ARE IN THE LIVING ROOM. THERE IS A
DOOR TO THE EAST, A WOODEN DOOR WITH
STRANGE GOTHIC LETTERING TO THE WEST,
WHICH APPEARS TO BE NAILED SHUT, A
TROPHY CASE, AND A LARGE ORIENTAL RUG IN
THE CENTER OF THE ROOM.
ABOVE THE TROPHY CASE HANGS AN ELVISH
SWORD OF GREAT ANTIQUITY.
A BATTERY-POWERED BRASS LANTERN IS ON
THE TROPHY CASE.

The entrance to the underground in Adventure, you may remember, was through a grate set into the ground in the forest. Zork has a similar grate, but it serves only as an homage to its inspiration and a red herring; the real entrance is right here in the living room, beneath the rug.

>MOVE RUG
WITH A GREAT EFFORT, THE RUG IS MOVED TO
ONE SIDE OF THE ROOM. WITH THE RUG
MOVED, THE DUSTY COVER OF A CLOSED
TRAP-DOOR APPEARS.
>EXAMINE WOODEN DOOR
THE ENGRAVINGS TRANSLATE TO 'THIS SPACE
INTENTIONALLY LEFT BLANK.'
>OPEN TRAP-DOOR
THE DOOR RELUCTANTLY OPENS TO REVEAL A
RICKETY STAIRCASE DESCENDING INTO
DARKNESS.
>D
THE TRAP DOOR CRASHES SHUT, AND YOU HEAR
SOMEONE BARRING IT.
IT IS PITCH BLACK. YOU ARE LIKELY TO BE
EATEN BY A GRUE.
YOUR SWORD IS GLOWING WITH A FAINT BLUE
GLOW.

And so we are underground. We’ll continue our explorations there next time.

 
 

Tags: , ,

Parser Games

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.

 
 

Tags: , ,

Selling Zork

When we left off, it was late summer, 1979, and seven of the nine partners involved with Infocom were living in Boston, working various day jobs, and discussing as time allowed just what the newly minted company should actually do. Meanwhile, the other two partners, Marc Blank and Joel Berez, were living in Pittsburgh and doing something more practical about the question, designing — entirely on paper at this stage — a system for getting Zork (or at least half of it) from the PDP-10 to the microcomputer. As Blank and Berez continued their work that fall, they became more and more convinced that, yes, this could actually work, and so began lobbying the others back in Boston to make Zork Infocom’s first project. Their case was compelling enough that even a reluctant Al Vezza finally agreed.

As it happened, Berez had been accepted for a graduate business program at MIT’s Sloan School of Management. He moved back to Boston that November for that — and to take the title of President of the still largely theoretical Infocom. Faced with being trapped in Pittsburgh all by himself while his friends implemented his designs, Blank made the rather personally momentous decision to drop out of his medical residency and come to Boston as well. Thus, as 1980 dawned the proverbial gang was all back together again, and work on a new Zork was proceeding apace.

With their connections at MIT and DEC, PDP-10 computer time was not hard to come by even for those at Infocom who had officially left MIT. Indeed, for all that their ultimate goal was to sell Zork on the micros, Infocom continued at this stage to do their work entirely on the PDP-10; perhaps the old motto of “We hate micros!” was still not entirely dead. Blank and Lebling wrote on the PDP-10 the complete ZIL development system, including the compiler and, for testing purposes, the first working Z-Machine virtual machine. Remarkably, the conceptual design that Blank and Berez had sketched out on napkins and scrap paper turned out perfectly workable in reality. As I noted in my last post, the reimplementation in ZIL even gave them the opportunity to improve on the original Zork in some ways.

Even when the time came to leave the PDP-10, Infocom’s biases showed through; the second Z-Machine implementation was not for a Radio Shack or an Apple, but for a DEC PDP-11. While the PDP-10 was DEC’s flagship model, big and powerful enough that it probably deserves to be labeled a mainframe rather than a minicomputer, the PDP-11 was the company’s smaller, cheaper bread-and-butter model. DEC is estimated to have sold over 170,000 of them during the 1970s alone. Relatively portable (if being able to move a computer with only a single van can count as “portable”) and requiring no raised floor or other data-center machinations, PDP-11s were everywhere: in factories, in laboratories, in air-traffic control centers — and in Joel Berez’s bedroom(!). The PDP-11 already had a Zork in a sense, having been the first target platform of that FORTRAN port of Dungeon, but that didn’t stop Infocom from making PDP-11 Zork their first commercial product. Relatively ubiquitous as the PDP-11 was, the market was not exactly a commercial gaming stronghold; Zork reportedly sold less than 100 copies there. (One of which recently surfaced on eBay; see Jason Scott’s Get Lamp site for a scan of the surprisingly thorough — albeit typewritten and mimeographed — manual.) Clearly, Infocom needed to get Zork onto the microcomputers.

In that spirit, Infocom purchased a TRS-80 system, and Scott Cutler, one of the few partners with any real microcomputer experience, set to work with Blank’s help to build a Z-Machine for it. The moment of truth came at last:

Scott and Marc demonstrated that Zork I was alive in it by starting the game and actually collecting points with the incantation “N.E.OPEN.IN.” (It’s certainly no less inspiring than “Come here, Mr. Watson; I want you!”)

It’s always a fraught moment when a programming project finally comes to life and does something. I remember my excitement when my own Z-Machine interpreter, Filfre, first printed out the opening text to the first game I elected to test it with, Infidel. I can only imagine Blank and Cutler’s excitement, when all of this was so new and the stakes were so much higher. Anyway, the Z-Machine concept worked. Once the game was completely playable, Infocom, heirs to an institutional computing tradition of doing things the right way, did something virtually unprecedented for a microcomputer game: they put their new game through rigorous, repeated testing. Their star tester was an MIT student named Mike Dornbrook, who fell in love with the game and obsessed over it endlessly, crafting lovingly detailed maps of its geography and working to iron out not just technical problems but dodgy puzzles and parser difficulties. (If only On-Line Systems, Scott Adams, and other developers had a similar patience and commitment to quality in these early days…)

Ongoing testing aside, Infocom had a real, marketable product. Now they just needed to decide how to sell it. One option was to do what Ken Williams was deciding to do at about this time, to go it alone. With little experience or knowledge of the young microcomputer industry, however, that seemed risky, and no one was excited about trying to devise packaging and duplicating thousands (hopefully!) of disks. They therefore began shopping Zork to publishers. An approach to Microsoft was rebuffed by the marketing department; they already had their own text adventure, Adventure itself, and apparently felt one was enough for any publisher. Later Bill Gates, who was a fan of the PDP-10 Zork, heard about the offer and tried to reopen the subject, but by then Infocom was already in talks with Dan Fylstra of Personal Software, leaving a Microsoft Zork to history as a fascinating might-have-been.

Personal Software has largely been forgotten today, but at the time it was the brightest star of the young software industry, easily eclipsing Microsoft. Founded by Peter R. Jennings and Fylstra, a founding editor of the seminal Byte magazine, PS hit a goldmine in 1979 when it reached an agreement with Dan Bricklin and Bob Frankston to publish VisiCalc for the Apple II. Aided by some smart PS advertising that properly emphasized the revolutionary nature of this truly revolutionary product, VisiCalc was by the time Infocom came calling the talk of the business world and the software hit of the young microcomputer industry, eventually selling in the hundreds of thousands. VisiCalc not only made PS the biggest software publisher on the planet and the subject of profiles by the likes of Time magazine, but also gave them huge power within the industry. This power extended even to Apple itself; countless customers were putting the cart before the horse, buying Apple IIs just to have a computer to run their new copy of VisiCalc on. It was the first “killer app” of the PC era, and sold all of the Apple IIs that that label would imply. With money and power like that, PS certainly seemed not a bad way for Infocom to get their new game out there. Fylstra had attended business school at MIT, and was acquainted from there with both Vezza and the PDP-10 version of his product. It didn’t take Berez and Vezza much time to get a deal done which even included a sorely needed advance on future royalty payments, what with Infocom having pretty much spent their initial $11,500 on hardware, testers, and PDP-10 time.

In between their other tasks, the other partners wrote a couple of magazine articles to help drum up anticipation. “How to Fit a Large Program into a Small Machine,” a cagey explanation of the concepts of the virtual machine and virtual memory, appeared in Creative Computing that July; “Zork and the Future of Computerized Fantasy Simulations,” a more theoretical article on the burgeoning art of the text adventure, appeared in Byte‘s big “adventure” issue in December. Having not yet come up with the elegant name of “interactive fiction,” Lebling saddled Zork and its peers with the rather unwieldy “computerized fantasy simulations” (“CFS”) label in the latter. As it appeared the TRS-80 version of Zork was just coming onto the market under the PS imprint.

Initial sales were not overwhelming; the TRS-80 version sold about 1500 copies in its first nine months. This figure can perhaps be partly attributed to the unimaginative and halfhearted marketing of PS, who in the wake of the VisiCalc juggernaut were increasingly uncertain whether they wanted to be involved with games at all. It’s also true, however, that the TRS-80 software market never really thrived in the way that sales of TRS-80 hardware might make you expect. A big culprit was Radio Shack’s own policies. They insisted on selling in their stores only software published under their own imprint. Yet they offered developers a very paltry royalty compared to the rest of the industry, and refused to even properly credit them on the software itself, preferring the image of an all-benevolent Tandy Corporation that apparently dropped immaculate software creations out of its rear end. Owners of other computer stores, meanwhile, such as the ComputerLand outlets that were exploding across the country, left Radio Shack to sell and service its own machines, instead concentrating on other platforms. It’s likely that the TRS-80 Zork fell at least partially into this distributional black hole that was already in danger of making the TRS-80 an also-ran in contrast to the young microcomputer industry’s newly anointed darling, the Apple II. In fact, that very December Apple went public, making its founders and about 300 others instant millionaires — the first big tech IPO, and a sign that soon the “microcomputer industry” would just be the “computer industry.”

Speaking of which: Bruce Daniels, the only member of the original Zork team who hadn’t joined Infocom, had accepted a job with Apple and moved to California after graduation. He agreed to create a Z-Machine for the Apple II under contract. Apple II Zork was released in February of 1981, and it did much better than the TRS-80 version, selling a steady 1000 copies per month. Infocom now had a steady stream of revenue at last, along with the basic technological infrastructure — ZIL and the Z-Machine — that would define the company for the rest of its life. Things were starting to look pretty good — but twists and turns were just ahead.

We’ll talk about them soon enough, but next time I want to leave the historical reality behind for a while in favor of virtual reality. Yes, we’re going to take a little tour of Zork‘s Great Underground Empire.

 
 

Tags: , , ,

ZIL and the Z-Machine

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 out them 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 enact, 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.

 
 

Tags: , ,