RSS

Monthly Archives: January 2012

Robot War

If you want to understand how different the computer world of 1981 was from that of today, a good place to look is the reception of Silas Warner’s programming game, Robot War. It received big, splashy feature articles in Softalk, the early flagship of the Apple II community, as well as the premiere issue of Computer Gaming World, one of the first two computer magazines unabashedly dedicated just to games. (Softline, a spinoff of Softalk, edged it out by just a hair for the prize of first.) In the only metric that ultimately matters to a publisher, it even bounced on and off of Softalk‘s monthly lists of the top 30 Apple II software bestsellers for a year or so. All this for a “game” that involved a text editor, a compiler, and a debugger — a game that sounds suspiciously like work to modern ears. But in 1981 the computer world was still a comparatively tiny one, and virtually everyone involved knew at least a little bit of programming as a prerequisite to getting anything at all done; most home computers booted directly into BASIC, after all. More abstractly, even the hardcore gamers (not that that term had yet been invented) were as fascinated with the technology used to facilitate their obsession as they were with games as entities unto themselves. In this milieu, a programming game didn’t sound like quite such an oxymoron.

Robot War was by far the most ambitious game Silas had yet created for Muse, a dramatic departure from simple BASIC excursions like Escape! Not coincidentally, it was also the first he created after finally agreeing to come to Muse Software full time in 1980. He did already have a leg up on it to start, for Robot War on the Apple II is basically the same game as the version he had programmed for the PLATO system a few years before. It does, however, offer some enhancements, most notably the ability for up to five robots to battle one another at one time in a huge free for all; the original had offered only one-on-one matches.

While they didn’t approach software development as systematically as did Infocom, Muse had developed some unusually sophisticated tools by this stage to make assembly-language coding a less arduous task. At a time when other shops seemed to accept perpetual reinventing of wheels as a way of life, Muse had also gotten quite good at reusing its code wherever possible. Large chunks of Robot War, for instance, are lifted straight out of Super-Text, the company’s word processor. One edits one’s source code in a streamlined version of Super-Text itself. Employing one of the strangest criteria for recommending a game ever, Softalk noted that playing Robot War makes “learning the real Super-Text a snap.”

The other way that Super-Text helped beget Robot War is more surprising, and gives me the opportunity to make one of my little lessons in technology — specifically, computer display technology.

The screen on which you’re reading this is almost certainly a bitmapped display. This means that it is seen by the computer as just a grid of colored pixels. The text you’re reading is mapped onto that grid in software, “drawn” there like an unusually intricate picture. This is a cool thing for many reasons. For one, it allows you to customize things like the size, shape, and style of the default font to suit your own preferences. For another, it allows writers like me to play with different typefaces to get our message across. It’s a particularly nice thing for word processing, where a document on the screen can be rendered as a perfect — or at least nearly perfect — image of what will appear when you click “Print.” (We call this what-you-see-is-what-you-get, or WYSIWYG). It’s also got some disadvantages, however: rendering all of that text letter by letter and pixel by pixel consumes a lot of processing power, and storing that huge grid of pixels consumes a lot of memory. The screen on which I’m writing this is 1920 X 1200 pixels. At the 4 bytes per pixel needed to display all the colors a modern computer offers — another, separate issue — that amounts to about 9 MB. That number is fairly negligible on a machine with 4 GB of memory like this one, but on one with just 48 K like the Apple II, even accounting for the need to store vastly fewer colors and a vastly lower resolution, it can be a problem. So, the standard, default display mode of the Apple II is a textual screen, stored not as a grid of individual pixels but as a set of cells, into each of which a single letter or a graphical glyph — essentially a “letter” showing a little glyph which can be combined with others to draw frames, diagrams, or simple pictures — can be inserted. Rendering these characters to the screen is then handled in the display hardware rather than involving any software at all. This approach has plenty of disadvantages: one is limited to a single font; said font must be mono- rather than variable-spaced; changing the font’s size or style are right out; etc. On the plus side, it’s fast and it doesn’t use too much memory. In fact, the Apple II was unique among the trinity of 1977 in offering a bitmapped graphics mode at all; the TRS-80 and PET offered only character-oriented displays. The Apple II’s Hi-Res mode is much of the reason it stood out so amongst its peers as the Cadillac of early microcomputers.

One would naturally expect a word processor — about the most text-oriented application imaginable — to work in the Apple II’s text mode. As Ed Zaron of Muse was developing Super-Text, however, he had to confront a problem familiar to makers and users of much early Apple II application software. The Apple II’s text mode could display just 40 big, blocky characters per line. Amongst other reasons, this design decision had been made because the machine’s standard video feed was just an everyday, fairly low-quality analog television signal. Trying to display more, smaller characters, especially on the television many users chose in lieu of a proper monitor, would just result in a bleeding, unreadable mess. The problem for word processing and other business applications was that a standard typewritten page has 80 characters to a line. Thus, and even though the word processor was not going to be anything close to WYSIWYG under any circumstances given the other limitations of the Apple II’s display, it was even harder than it might otherwise be for the user to visualize what a document would look like in hard copy while it was on the screen, what with each hardcopy line spread over two onscreen. Zaron therefore considered whether he might be able to use Hi-Res mode to display 80 characters of text, at least for those whose displays were good enough to make it readable.

The problem with that idea, however, was that the Apple II has no built-in ability to render text to the Hi-Res screen. One can paint individual pixels, even draw lines and simple shapes, but there is no facility to tell the machine to, say, draw the letter “A” at position 100 X 100. Zaron therefore spent considerable time developing a Hi-Res character generation of his own — a program that could essentially render little pictures representing each glyph to the screen on command, just as your display works today. Zaron and Muse ultimately decided the idea just wasn’t viable for Super-Text. Even with a good monitor it was just too ugly to work with for long periods of time given the color idiosyncrasies of Hi-Res mode, and it was unacceptably slow to work with for entering and editing text. Besides, by that time something called the Sup’R’Terminal was available from a company called M&R Enterprises. This was a card which plugged into one of the Apple II’s internal slots (bless Woz’s foresight!) and solved the problem by adding an entirely new, alternate display system that could render 80 columns of text quickly and cleanly. It also solved another problem for word processors in being able to render lower-case as well as upper-case text (the original Super-Text had had to distinguish upper case from lower case by highlighting the former in reverse video). Soon enough an array of similar products would be available, eventually including some from Apple itself. So, Zaron’s character generator went on the shelf…

…to be picked up by Silas Warner and incorporated into Robot War. While plenty of games made use of the Apple II’s split-screen mode which allowed a few lines of conventional text to appear at the bottom of a Hi-Res display, the screenshot above is one of the few examples in early Apple II software of dynamically updated text being incorporated directly into a Hi-Res display, thanks to Zaron’s aborted Super-Text character generator. Sometimes software development works in crazy ways.

Even if you aren’t a programmer, the idea of Robot War — of programming your own custom robot, then sending him off to do battle with others while you watch — is just, well, neat. That neatness is a big reason that I can’t resist taking some time to talk about it here, where we’re usually all about the ludic narrative. Of course, given the technological constraints Silas was working with there are inevitable limits to the concept. You don’t get to design your robot in the physical sense; each is identical in size, in the damage it can absorb, in acceleration and braking, and in having a single rotatable radar dish it can use to “see” and a single rotatable gun it can use to shoot. The programming language you work with is extremely primitive even by the standard of BASIC, with just a bare few commands. Actual operation of the robot is accomplished by reading from and writing to a handful of registers. That can seem an odd way to program today — it took me a while to wrap my mind around it again after spending recent months up to my eyebrows in Java — but in 1981, when much microcomputer programming involved PEEKing and POKEing memory locations and hardware registers directly, it probably felt more immediately familiar.

Here’s a quick example, one of the five simple robots that come with the game.

;SAMPLE ROBOT 'RANDOM'

] 250 TO RANDOM ;INITIALIZE RANDOM — 250
MAXIMUM
]
]START
] DAMAGE TO D ;SAVE CURRENT DAMAGE
]
]SCAN
] IF DAMAGE # D GOTO MOVE ;TEST — MOVE IF HURT
] AIM+17 TO AIM ;CHANGE AIM IF OK
]
]SPOT
] AIM TO RADAR ;LINE RADAR WITH LAUNCHER
] IF RADAR>0 GOTO SCAN ;CONTINUE SCAN IF NO ROBOT
] 0-RADAR TO SHOT ;CONVERT RADAR READING TO
]DISTANCE AND FIRE
] GOTO SPOT ;CHECK IF ROBOT STILL THERE
]
]MOVE
] RANDOM TO H
] RANDOM TO V ;PICK RANDOM PLACE TO GO
]
]MOVEX
] H-X*100 TO SPEEDX ;TRAVEL TO NEW X POSITION
] IF H-X>10 GOTO MOVEX ;TEST X POSITION
] IF H-X ] 0 TO SPEEDX ;STOP HORIZONTAL MOVEMENT
]
]MOVEY
] V-Y*100 TO SPEEDY ;TRAVEL TO NEW Y POSITION
] IF V-Y>10 GOTO MOVEY ;TEST Y POSITION
] IF V-Y ] 0 TO SPEEDY ;STOP VERTICAL MOVEMENT
] GOTO START ;START SCANNING AGAIN
]

Let’s just step through this quickly. We begin by plugging 250 into the RANDOM register, which tells the robot we will expect any random numbers we request to be in the range of 0 to 249. We store the value currently in the DAMAGE register (the amount of damage the robot has received) into a variable, D, for safekeeping. Immediately after we test the DAMAGE register against the value we just stored; if the former is now less than the latter, we know we are taking fire. Let’s assume for the moment this is not the case. We therefore add 17 to the AIM register, which has the effect of rotating our gun 17 degrees around a 360-degree axis. We send a pulse out from our radar dish in the same direction that the gun is now facing. If the radar spots another robot, it will place a number representing the negation of its distance from us into the RADAR register; otherwise it places a 0 or a positive number there. (Yes, this seems needlessly unintuitive; Silas presumably had a good technical reason for doing it this way.) If we do find a robot, we fire the gun by placing the absolute value of the number stored in RADAR into the SHOOT register. This fires a shell set to explode that distance away. We continue to shoot as long as the robot remains there. When it is there no longer, we go back to scanning the battlefield for targets.

Should we start taking fire, we need to move away. In accordance with our name, we decide this by storing random numbers from 0 to 249 — the battlefield is grid of 256 X 256 — into two variables representing our desired new horizontal and vertical positions, H and V. What follows gets a little bit more tricky. The SPEEDX and SPEEDY registers represent horizontal and vertical movement respectively, with negative numbers representing movement to the left or upward and positive numbers to the right or downward. For an added wrinkle, we can only accelerate or decelerate 40 units per second, regardless of what we place in these registers. So, we’re figuring out the relative distance and direction of our goal to our current position, which we find by reading registers X and Y, then moving that way by manipulating SPEEDX and SPEEDY. Because this is not a terribly sophisticated robot, we move into position on each axis individually rather than trying to move on a diagonal. Once we have reached our (approximate) goal, we settle down to scan and shoot once more.

So, what you’re really doing here is writing an AI routine of the sort that someone making a game from scratch might program. If nothing else, that makes it a great training tool for a prospective game programmer. Although one can have some fun playing against the robots that come with it, Robot War is really meant to be a multiplayer game, where one places one’s creations up against those of others. It begs for some sort of tournament, and in fact that’s exactly what happened; Computer Gaming World was so enamored with Robot War that they sponsored a couple in partnership with Muse. For each, several Apple IIs spent several weeks in the basement of Muse’s office/store crunching through battles to determine an eventual champion. I was intrigued enough by the idea to consider proposing a tournament here with you my gentle readers, but upon spending some time with the actual software I tend to think it’s just too crusty and awkward to modern sensibilities to garner enough interest. If you think I’m wrong, though, tell me about it in comments or email; if there’s real interest I’m happy to reconsider. Regardless, here’s the Apple II disk image and the manual for you to have a look at.

In common with another Silas Warner game of 1981, Robot War had a cultural impact far beyond what its sales figures might suggest. It was common enough even in 1981 for computer programs to model the real world, in the form of flight simulators, war games, etc. The subject matter of Robot War, however, went in the opposite direction when something called the “Critter Crunch” took place in Denver in 1987. Today real-world robot combat leagues are kind of a big deal, with their matches often televised and given exposure that any number of human sports would kill to have. I can’t say all of this wouldn’t have started without Silas Warner’s game, but it’s perhaps more than just coincidence that two of the first sustained robot-combat leagues were called Robot Wars, as were a couple of the robot-combat television series (one of which, ironically, turned back into a videogame series). Even more definitive is the influence Robot Wars exerted on the programming games that followed it. The most obvious direct homage is Robot Battle, but there’s plenty of the Robot War DNA in more mainstream efforts like MindRover, not to mention plenty of free hacker-oriented programming games which may or may not involve actual robots. And to think that Robot War was just Silas Warner’s second most influential game of a prodigious 1981…

We’ll get to that other game, which actually bears more directly on this blog’s usual obsessions, soon. First, though, I want to grab one of these other balls I’ve got in the air and check in with one of our old friends.

 
 

Tags: , ,

Silas Warner and Muse Software

Silas Warner was born in Chicago on August 18, 1949, the first and only child of Forrest and Ann Warner. Their family situation was fraught, with Ann and Silas allegedly suffering physically and mentally at the hands of Forrest. Although they couldn’t prove it, it’s a measure of how bad the situation was that both believed that Forrest attempted to kill them by tampering with the brakes on Ann’s car when Silas was 5. Shortly after, they fled Chicago to return to Ann’s home town of Bloomington, Indiana. With the support of her family, Ann earned a degree in education from Indiana University and began teaching. Silas never had any personal contact with his father for the rest of his life.

Ann never remarried, but rather built her emotional world around Silas. She could happily talk for hours about her son, whom she devoutly believed was “special,” destined for great things. As evidence, she claimed that he had already begun reading at the age of two. Later she would brag about his alleged perfect score on his SAT test, or his scholarship offers. She encouraged him to immerse himself in books and intellectual pursuits even as he physically grew up to be a veritable giant, almost seven feet in height and well over 300 pounds in weight. The portrait that emerges on a site offering reminiscences is of an intellectually prodigious and essentially good-hearted but — to put it mildly — socially challenged person. He often struck others as just a little bit sad. A cousin writes about playing on visits with the elaborate train set he’d constructed, but also says that “it was really hard to talk to him. He didn’t seem to know how to carry on a conversation or even really how to ‘play.’ I have to say I just felt sorry for him.” His mother didn’t help the situation by actively discouraging him from having much contact with even his cousins, whom she judged “not up to his caliber of intelligence.” With his social ineptitude, his weight, and the clothes that Ann made for him because she couldn’t purchase any big enough, Silas had a predictably rough time of it in high school. Even a flirtation with football only left him with an injury that would bother him for the rest of his life. On the other hand, his size was intimidating, and he could display a vicious temper when sufficiently roused; he knocked at least one bully unconscious.

Silas entered Indiana University’s physics program in 1966. (It’s a funny thing that so many hackers — Will Crowther and Ken Williams also among them — first entered university as physics majors in the days when computer-science programs and computer access in general weren’t so common. It must have something to do with being attracted to complex systems.) At university Silas continued his eccentric ways. A fellow student speaks of him “walking campus in his long black trench coat reading advanced chemistry and physics textbooks only inches from his face.” More surprisingly, he became “a reporter for the campus radio station, toting his portable reel-to-reel tape recorder gathering stories.”

He also discovered computers at Indiana University. In fact, he found a job working with them before he even graduated, dividing his senior year between his studies and a contract programming job developing accident-analysis software in COBOL for an IBM mainframe. After finishing his degree in 1970, he stayed at the university as an “undergraduate assistant,” an interface of sorts between the student body and the arcane world of the university’s computer systems. That put him in an idyllic position when PLATO came to Indiana University.

I’ve had occasion to mention the PLATO system before on this blog when I described the earliest computerized adaptations of Dungeons and Dragons that were hosted there. I’ve also mentioned Control Data Corporation, who built the mainframe and custom graphical terminals that ran PLATO in addition to giving a young Ken Williams his entree into the computer industry. What I haven’t done, however, is describe the link between the two.

CDC’s co-founder and CEO through its rise, glory years, and eventual downfall in the 1980s at the hands of the new microcomputers was a man named Bill Norris, who refused to accept the currently fashionable business dogma that a corporation’s only duty to society was to maximize profits and shareholder value. An odd combination of shrewd businessman and dreamy idealist, he attempted to use CDC as a force for social good by opening factories in economically depressed areas and funding experimental wind farms amongst a multitude of other projects. Even the Control Data Institute that gave Ken Williams his start was something of a do-gooder project of Norris’s, founded to give bright kids without university credentials a chance to build a career in the computer industry as well as to provide a pool of inexpensive workers for CDC. At a time when even most of his fellow computer-industry executives saw the machines primarily as tools of business, he believed that they could also be a source of social good. He therefore signed CDC on to be the technological and industrial partner of the PLATO system in 1963, just three years after Donald Blitzer had produced the first proofs of concept at the University of Illinois. With steady funding from the National Science Foundation, PLATO grew rapidly from there, with much of its development taking place at a new independent entity, the Computer-Based Education Research Laboratory (CERL), which stood halfway between the business pole of the program (CDC) and the academic pole (the University of Illinois). It would be silly to claim that CDC had no legitimate business interest in PLATO; CERL and PLATO delivered a steady stream of innovative new technologies and ideas to the company. Still, the relationship also reflected Norris’s unique approach to business with a social conscience.

As I wrote in that earlier post, PLATO really came of age with the PLATO IV iteration in 1972, which brought graphical display terminals out of Illinois for the first time to hundreds of institutions spread around the country and, eventually, the world. One of the first of those institutions was the University of Indiana, where Silas helped to set up the first terminals. Soon he was not just administering the system but contributing major pieces of courseware and other software. For instance, he authored “HELP,” a standard tutorial and introduction to the system for new users, and a “massive lesson menu system named IUDEMO.”

PLATO programs — optimistically called “lessons” — were programmed in a language called TUTOR that was accessible to every user. This relatively easy-to-use language enabled much of the creativity of the PLATO community. It allowed educators and students with no knowledge of the vagaries of bits and bytes to design serviceable programs while also being powerful enough to create some surprisingly elaborate games, from dungeon crawls to flight simulators, board-game adaptations to shoot-em-ups. Many if not most of these games were multiplayer; you simply navigated to a “big board” of eager players, found a partner (or two, or more; some could support more than 50 simultaneous players, amounting to virtual worlds in their own right as well as games), and dived in. In addition to his more legitimate activities, Silas became deeply involved with this generally tolerated-if-not-encouraged side of PLATO. He helped John Daleske get started developing Empire, an early — possibly the first — multiplayer action game. Later, he developed his own variant of Empire, which he called Conquest. Another project was possibly the world’s first multiplayer flight simulator, called Air Race. On the theory that guns make everything more fun, Brand Fortner built from Air Race the multiplayer air-combat simulation Air Fight, which became one of PLATO’s biggest hits as well as one of its administrators’ biggest scourges; 50 or 60 active Air Fight players could bring PLATO’s million-dollar CDC mainframe to its knees.

CERL and CDC sometimes hired particularly promising PLATO programmers to work for them. That’s how Silas came to leave Indiana University at last in 1976, moving to Baltimore to work for Commercial Credit, a consumer lending company that was, oddly enough, wholly owned by CDC. Silas came in to develop various in-house training programs on PLATO, such as “Sales-Call Simulator,” an “educational adventure.” While he was about it, he also created his first hit game, Robot War. Each player would program the AI routines for her own robot, using a language Silas devised for the purpose that was essentially a subset of the TUTOR language that virtually every serious PLATO user already had at least some familiarity with. Then the robots would go at it, while the players watched and hoped. Robot War was the first of its kind, the first of a whole genre of programming games that remain a beloved if obscure preoccupation of some hackers to this day. (I’ll have much more to say about Robot War soon).

Silas became particular friends with two other Commercial Credit employees: Ed Zaron, a programmer in the credit scoring department; and Jim Black, an accountant in the billing department. Zaron describes his introduction to the always eccentric Silas:

Silas is one of a kind. I’ll never forget first meeting him. Silas is a big guy, maybe 6’8″ and say 320lbs. Here’s the picture, he was walking down mainstreet in downtown Baltimore wearing a huge, sagging sports coat. He had a car battery (yes, car battery!) in one pocket, a CB radio in the other pocket and a whip antenna stuck down the back of his jacket. He was occasionally talking on the CB as he held two magazines open in one hand. One of Silas’s favorite things was to read two mags simultaneously, kinda one inside the other, flipping back and forth.

This was just about the time that the microcomputer trinity of 1977 arrived. Silas, Zaron, and Black all became very early Apple II adopters; Silas, for instance, ended up with serial number 234. Like Scott Adams and others with the programming skills to make the machines do something at least ostensibly fun or useful, the three decided to form a company — Muse Software. Their first products were, like most early Apple II software, programmed in BASIC.

Muse debuted with two games. There was Zaron’s Tank Wars, a multiplayer arcade-style game similar to the Atari 2600’s original Combat. And there was a maze game by Silas, which presented its world to the player via a first-person, three-dimensional rendering, possibly the first such ever crafted for a microcomputer. The concept was, however, old hat on PLATO, where similar so-called “maze runners” were a popular genre. Indeed, Muse’s PLATO experiences would prove to be a fecund source of inspiration, as they continued to adapt ideas born of that system’s flourishing games community for the little micros. Within a few months Silas had expanded his maze game to create Escape!, the game which inspired Richard Garriott to make 3D dungeons a part of Akalabeth and, by extension, the Ultimas. Escape! killed productivity inside Apple itself, as described by David Gordon, the man responsible for introducing it there:

On one of my first trips to Apple Computer in 1978 I took with me a simple maze game called Escape by a fledgling company called Muse. Apple had 50 or 60 employees at the time and I created a work loss of approximately 60 man weeks because everyone at Apple was playing that game instead of working. They were charting out the mazes and trying to solve the puzzle.

Muse’s simple programs, which they pumped out at a prodigious rate and packaged themselves using art provided by Black’s girlfriend, proved to be surprisingly popular. Weary of spending their evenings copying cassettes and their weekends touring the East Coast trade-show circuit, Zaron and Black soon quit their jobs at Commercial Credit to make a real, entrepreneurial go of it, although a more cautious Silas stayed on there until 1980. With public-relations skills like this, maybe it was for the best that Silas didn’t have so much time for the shows:

I remember in the early days of MUSE, I attended a “Computer Show” in Philadelphia with my dad and Silas. He had just written that Voice/Music program for the Apple II, which attracted a pretty big crowd. The big thing then was selling and trading programs recorded on cassette tapes. Hilarious! Anyway, it was great to see Silas pitching the programs and working with people. You really got to see what they were made of when he would stop talking, reach into his nose and pull out a gigantic booger, and then wipe it on the underside of the nearest table or chair, and continue with the demonstration. He was really great.

Muse’s early catalogs contained a shambolic line of programs typical of other early software houses like Adventure International and On-Line Systems. In addition to the games, there were drawing programs, programming utilities, educational drills, text editors. By 1980, however, disks and the spacious 48 K of memory that came in the Apple II Plus were becoming the accepted standard, and customers were beginning to expect more of their software. Muse created a development system of its own that allowed them to write fast assembly language programs while still having access to some of the conveniences and structure of higher level languages. With Silas on board full time at last, they also moved from their first office, a cramped space above a gun store, to lease a two-story building for themselves in downtown Baltimore. The top floor housed the business and software development arms, which now consisted of half a dozen employees, while the lower floor became the “Muse Computer Center,” a retail computer store selling Muse’s products as well as those of others. One non-obvious advantage of operating a store was that it allowed Muse to order products at dealer prices, making it easy to keep up with the competition’s latest in the fast-moving game of oneupsmanship that the Apple II software market was becoming.

In that spirit: Muse’s two major products of 1980 both advanced the state of the art. Zaron’s Super-Text was the most powerful and usable of the early Apple II word processors. And Silas’s The Voice let the user, incredibly, record her own voice and play it back, after a fashion, on the Apple II’s primitive sound hardware. This was absolutely unprecedented stuff. Both programs would play a big role in Silas’s two landmark games of the following year, about which more in my next post.

 
 

Tags: , ,

Escape!

Ever stumbled across something you’ve been looking for for a long time while you’re doing something else entirely? Well, I’ve just found the digital equivalent of my cat’s favorite toy which I found last week while reaching under the television stand to try to reset our infernal TV box. I’ve found the game Escape!, the Apple II maze game that inspired Richard Garriott to program the 3D dungeons of Akalabeth. Turns out it was written by Silas Warner of Muse Software, about whom I’ll have much more to say shortly. In the meantime, I’ve updated the old post on Garriott to reflect my discovery. Or, if you’d like to cut to the chase, here’s a screenshot and a disk image for ya. Type “RUN ESCAPE” after booting the disk to get started.

 
6 Comments

Posted by on January 23, 2012 in Digital Antiquaria, Interactive Fiction

 

Tags: , , ,

Exploring Zork, Part 3

Today we’ll finish up with Zork. That means plunging into the only big, completely traditional maze in the Infocom canon. And it’s a nasty one; apparently they decided that if you’re only going to do one, you might as well do it up right.

In keeping with the thief’s role as a stand-in for Adventure‘s pirate, the maze is where he has his lair. This fact, even more than its sheer size, is the root of its difficulty: as you wander about inside dropping items and mapping, chances are good that the thief will show up to scatter your carefully placed items about and leave you hopelessly confused. Like the combat sequences, success here requires luck and careful saving and restoring more than skill. Nowhere else does Zork so thoroughly justify Robb Sherwin’s statement that it “hates its player.”

Within the maze is the “CYCLOPS ROOM.”

>SE
CYCLOPS ROOM
THIS ROOM HAS AN EXIT ON THE NORTHWEST,
AND A STAIRCASE LEADING UP.
A CYCLOPS, WHO LOOKS PREPARED TO EAT
HORSES (MUCH LESS MERE ADVENTURERS),
BLOCKS THE STAIRCASE. FROM HIS STATE OF
HEALTH, AND THE BLOODSTAINS ON THE
WALLS, YOU GATHER THAT HE IS NOT VERY
FRIENDLY, THOUGH HE LIKES PEOPLE.

There are two possible solutions to the cyclops problem, one basically acceptable and one easily the worst in the game. For the former, we can give him the lunch we found in the house at the beginning of the game, followed by the bottle of water. The latter is another guess-the-word affair that makes the loud room look like design genius: we can type “ODYSSEUS.”

>ODYSSEUS
THE CYCLOPS, HEARING THE NAME OF HIS
FATHER'S DEADLY NEMESIS, FLEES THE ROOM
BY KNOCKING DOWN THE WALL ON THE EAST OF
THE ROOM.

But never fear, there is a “clue” to this solution. Reading a prayer book we found in the temple yields the following:

>EXAMINE BOOK
COMMANDMENT #12592

OH YE WHO GO ABOUT SAYING UNTO EACH:
“HELLO SAILOR”:
DOST THOU KNOW THE MAGNITUDE OF THY SIN
BEFORE THE GODS?
YEA, VERILY, THOU SHALT BE GROUND
BETWEEN TWO STONES.
SHALL THE ANGRY GODS CAST THY BODY INTO
THE WHIRLPOOL?
SURELY, THY EYE SHALL BE PUT OUT WITH A
SHARP STICK!
EVEN UNTO THE ENDS OF THE EARTH SHALT
THOU WANDER AND
UNTO THE LAND OF THE DEAD SHALT THOU BE
SENT AT LAST.
SURELY THOU SHALT REPENT OF THY CUNNING.

On the original PDP-10 implementation, reading the first letter of each line yields “ODYSSEUS.” On the 40-column Apple II screen, however, this rather breaks down. It’s an awful “puzzle,” but the fact that Infocom give the player a more reasonable alternative really marks them, for all their continuing design pratfalls, as unusual text-adventure developers for this era. Scott Adams or Roberta Williams would have just stuck the easy-to-implement “ODYSSEUS” puzzle in and dreamed of all the hint booklets they were about to sell.

Beyond the cyclops lies the thief’s lair. Giving him his reckoning feels sweet indeed after all the trouble he’s caused us, not to mention restoring to us whatever treasures he’s stolen.

>U
YOU HEAR A SCREAM OF ANGUISH AS YOU
VIOLATE THE ROBBER'S HIDEAWAY. USING
PASSAGES UNKNOWN TO YOU, HE RUSHES TO
ITS DEFENSE.
THE THIEF GESTURES MYSTERIOUSLY, AND THE
TREASURES IN THE ROOM SUDDENLY VANISH.
TREASURE ROOM
THIS IS A LARGE ROOM, WHOSE EAST WALL IS
SOLID GRANITE. A NUMBER OF DISCARDED
BAGS, WHICH CRUMBLE AT YOUR TOUCH, ARE
SCATTERED ABOUT ON THE FLOOR. THERE IS
AN EXIT DOWN A STAIRCASE.
THERE IS A SUSPICIOUS-LOOKING
INDIVIDUAL, HOLDING A BAG, LEANING
AGAINST ONE WALL. HE IS ARMED WITH A
VICIOUS-LOOKING STILETTO.
THERE IS A SILVER CHALICE, INTRICATELY
ENGRAVED, HERE.
THE THIEF RAMS THE HAFT OF HIS BLADE
INTO YOUR STOMACH, LEAVING YOU OUT OF
BREATH.
>KILL THIEF WITH AXE
YOU ARE STILL RECOVERING FROM THAT LAST
BLOW, SO YOUR ATTACK IS INEFFECTIVE.
YOU PARRY A LIGHTNING THRUST, AND THE
THIEF SALUTES YOU WITH A GRIM NOD.
>KILL THIEF WITH AXE
THE THIEF IS STRUCK ON THE ARM, BLOOD
BEGINS TO TRICKLE DOWN.
THE THIEF STABS NONCHALANTLY WITH HIS
STILETTO AND MISSES.
>AGAIN
THE BLOW LANDS, MAKING A SHALLOW GASH IN
THE THIEF'S ARM!
THE THIEF TRIES TO SNEAK PAST YOUR
GUARD, BUT YOU TWIST AWAY.
>AGAIN
THE BLOW LANDS, MAKING A SHALLOW GASH IN
THE THIEF'S ARM!
THE THIEF SLOWLY APPROACHES, STRIKES
LIKE A SNAKE, AND LEAVES YOU WOUNDED.
>AGAIN
THE THIEF IS STRUCK ON THE ARM, BLOOD
BEGINS TO TRICKLE DOWN.
THE THIEF STABS NONCHALANTLY WITH HIS
STILETTO AND MISSES.
>AGAIN
YOU CHARGE, BUT THE THIEF JUMPS NIMBLY
ASIDE.
THE THIEF STABS NONCHALANTLY WITH HIS
STILETTO AND MISSES.
>AGAIN
THE FATAL BLOW STRIKES THE THIEF SQUARE
IN THE HEART: HE DIES.

But wait… remember when I mentioned way back at the beginning of this adventure that the jeweled egg we found in the forest was key to the cruelest puzzle in the game? Well, I’m afraid we need to get the thief to do something for us before we kill him. We need to let him open the egg for us, for, as subtly hinted when we try to do it ourselves, we “HAVEN’T THE TOOLS OR EXPERTISE.”

With the maze explored and the thief employed and then promptly dispatched, we face only one last puzzle — but it’s another nasty one, a late addition that we could just as well have done without. From time to time while wandering in the forest, we “HEAR IN THE DISTANCE THE CHIRPING OF A SONG BIRD,” a message originally included as just a bit of flavor text. Tim Anderson:

Many people on the net had long since solved the game, but went back in and did any new problems that came along; one of them had played DD with Dave, and called him up about a day after the egg was announced. "I've gotten the egg opened, but I assume you losers have some nonsense where you do something with the canary and the songbird. Dave, no fool, said "Cough, cough, ahem, of course," and immediately went off and added the brass bauble.

Specifically, we need to wind the clockwork canary we found inside the egg to attract the songbird, which in turn drops a brass bauble at our feet — the 19th and final treasure. We place the lot in the trophy case, which magically opens up a new path outside.

>SW
STONE BARROW
YOU ARE STANDING IN FRONT OF A MASSIVE
BARROW OF STONE. IN THE EAST FACE IS A
HUGE STONE DOOR WHICH IS OPEN. YOU
CANNOT SEE INTO THE DARK OF THE TOMB.
>W
AS YOU ENTER THE BARROW, THE DOOR CLOSES
INEXORABLY BEHIND YOU. AROUND YOU IT IS
DARK, BUT AHEAD IS AN ENORMOUS CAVERN,
BRIGHTLY LIT. THROUGH ITS CENTER RUNS A
WIDE STREAM. SPANNING THE STREAM IS A
SMALL WOODEN FOOTBRIDGE, AND BEYOND A
PATH LEADS INTO A DARK TUNNEL. ABOVE THE
BRIDGE, FLOATING IN THE AIR, IS A LARGE
SIGN. IT READS: ALL YE WHO STAND BEFORE
THIS BRIDGE HAVE COMPLETED A GREAT AND
PERILOUS ADVENTURE WHICH HAS TESTED YOUR
WIT AND COURAGE. YOU HAVE GAINED THE
MASTERY OF THE FIRST PART OF THE GREAT
UNDERGROUND EMPIRE. THOSE WHO PASS OVER
THIS BRIDGE MUST BE PREPARED TO
UNDERTAKE AN EVEN GREATER ADVENTURE THAT
WILL SEVERELY TEST YOUR SKILL AND
BRAVERY!
PLAY "ZORK: THE GREAT UNDERGROUND
EMPIRE, PART II".
YOUR SCORE WOULD BE 350 (TOTAL OF 350
POINTS), IN 1313 MOVES.
THIS SCORE GIVES YOU THE RANK OF MASTER
ADVENTURER.

And that, my friends, is Zork, a flawed creation but a tremendous advance over what had come before. And Infocom were just getting started.

I’ll have much, much more to say about Infocom in the future. But next, something completely different.

 
 

Tags: , ,

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 be 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: , ,