RSS

Tag Archives: apple ii

Mystery House, Part 1

When we left Ken and Roberta, they had just made the momentous decision to use the Apple II’s bitmap graphics capabilities to create an adventure game that featured pictures in addition to text. Roberta would be the first to admit that she was no artist, but she was up to creating some sketches that would suit the purpose; in a world with no graphic adventures at all, people after all wouldn’t be too inclined to criticize the aesthetics of the first one to appear. Still, pulling it off would require them to overcome two other challenges: how to get the pictures into the Apple II in the first place, and how to store them in such a way that they didn’t consume too much space on disk. This latter problem arose because Ken and Roberta were determined to provide pictures for every single location in the game, amounting to some 30 illustrations in all.

Creating pictures on the Apple II was a dicey proposition in early 1980, due not only to a dearth of usable paint programs but also to the lack of a suitable input device to use with them; mice were still years away, while drawing with a joystick, trackball, or keyboard was an inevitably sloppy, frustrating process. Ken and Roberta therefore ended up purchasing an ungainly contraption called a VersaWriter.

The VersaWriter was far too persnickety to allow for free-hand drawing. The user was rather expected to insert a sketch under the transparent surface of the drawing area, and then to trace it using the stylus. The device was marketed as a tool for getting diagrams — flowcharts, circuit diagrams, floor plans, etc. — into the Apple II; its packaged software did not deal very well with the irregular lines and patterns typical of full-blown pictures. Apple itself had actually released a drawing tablet much more suitable for illustrations the previous year. Apple’s tablet, however, cost $650, while the VersaWriter could be had for less than $200. Still uncertain about this whole enterprise and desiring to do it on the cheap, Ken went with the VersaWriter. Now he needed to find a way to make it work. Like a good hacker, he promptly set to work writing his own software to operate it. In doing so, he actually solved his second challenge almost accidentally.

Storing 30 or more images on disk as simple grids of pixels would consume far more space than Ken had available on a single disk. If he wished to avoid the hassle of shipping the game on many disks and asking the user to swap among them, he needed to find a better way. With compressed graphics standards still unheard of (and likely too taxing on the little Apple’s 6502 if they had been), Ken hit upon the idea of storing each picture not as the data that made up the final product, but rather as a series of drawing commands that could be used to create it afresh. In other words, instead of being fetched from disk, the pictures in Mystery House are “drawn” anew by the computer each time they appear. (Or, for the more technically inclined: they are stored as vector graphics, not raster graphics.) The really elegant bit is that the drawing statements used to create them correspond with the motions of the stylus that traced them on the VersaWriter. Thus to store his graphics Ken needed only “record” the motions of the stylus as it traced Roberta’s simple drawings, then “play back” those motions on the screen when called for in the game. It’s a masterful little hack, one that shows how far Ken had come as a programmer from his days as a drone-in-training at Control Data Institute.

Combined with a simple parser and world model about on the level of the Scott Adams games, the final product looked like this.

No, the graphics aren’t exactly lush. If you can bear with me getting just a bit technical for a moment, it makes a great exercise in platform studies to ask just why they look like they do.

The Apple II’s normal “Hi-Res” graphics mode provides a bitmap display of 280X192 pixels. The programmer can, however, optionally choose to reserve the bottom 32 pixels of the screen to display the bottom of the Apple II’s regular text screen, which lives elsewhere in memory. This mode proved perfect for a game like Mystery House, as well as plenty of others soon to come from On-Line Systems and others. Because the text screen persists elsewhere, one convenience feature is very easy to program: the player can, just by hitting enter on a blank input line, make the picture disappear, revealing her last several turns.

Another tap of the enter key instantly restores the hi-res overlay, which has remained in memory. This was quite slick stuff in 1980, and the Apple II makes it trivial. It’s perfect for a game like Mystery House, almost as if Wozniak had anticipated this application when he designed it.

But, you might be wondering, why the bizarre coloration in the illustrations? To answer that, we need to look a bit more deeply at the way that hi-res mode works.

A bitmap graphics display is normally stored in memory as a long string of bits which are constantly fetched and painted to the screen. The exact amount of memory needed for the purpose obviously depends on the resolution of the display. But slightly less obviously, it also depends on the number of colors in our palette. If we allow just 2 colors (probably black and white), we need but one bit for each pixel. If we want to allow more, though, we need more memory. A 256-color palette, for instance, requires 8 bits, or 1 byte, to store each individual pixel. You are probably reading these words on a 24-bit color screen with a palette of well over 16 million colors, which must devote 3 full bytes to representing every pixel. (This mode is often inaccurately termed 32-bit color because modern hardware is happy to waste one full byte on every pixel to keep things aligned in a tidy way.)

Numbers like these were, of course, inconceivable in 1980. The Apple II Plus offered just 6 colors in hi-res mode. If you apply what you learned back in Computer Literacy, you can quickly conclude that we would need to devote 3 bits to each pixel to store an Apple II bitmap in the conventional way. (Using 3 bits actually gives a range of possible numbers between 0 and 7, which is overkill; 2 bits, however, is too few.) Let’s do a quick calculation: 3 bits per pixel * 280 horizontal pixels * 192 vertical pixels = 161,280 bits, or (dividing by 8) 20,160 bytes (a bit under 20 K). Now consider that we have 48 K of memory total available on the Apple II; devoting almost half of it to the display is untenable if we also want to be able to write programs of any complexity at all to actually take advantage of hi-res mode.

These realities weren’t lost on Wozniak. As in so many other areas of the Apple II, he came up with a way to do more with less. Rather than devote 3 bits to each pixel, he devoted just 1 — but reserved one bit in each byte for a special purpose, about which more in a moment. Then he defined a set of simple rules to determine what color each pixel would be. If a bit is not set, the pixel it corresponds to on the screen is also “off,” or black. If a bit is on, and the bit to either its left and/or its right is also on, that pixel appears as white. If a bit is on, is on an even x-coordinate, and the adjacent bits are both off, that pixel appears as violet or blue, depending on whether that eighth, reserved bit is set or not. A bit on an odd x-coordinate in the same situation follows the same rules to arrive at a green or orange pixel. This setup allows us to store a 280X192 6-color screen using only 7680 bytes. It brings with it, however, a collection of restrictions:

  • A white pixel must have at least 1 other white pixel to its left or right. (In other words, a vertical white line drawn on the screen must be at least 2 pixels wide.)
  • A pixel on an even horizontal coordinate can allegedly be white, black, violet, or blue, but not green or orange. If, however, the bit in question is off, and a colored pixel is adjacent, that color “bleeds over” to color in this supposedly black pixel.
  • Similarly, a pixel on an odd horizontal coordinate can allegedly be white, black, green, or orange, but not violet or blue, subject to the same process as above.
  • Each horizontal line consists of 280 pixels, but these are divided into 40 groups of 7. Pixels within each group can be violet or green, or blue or orange, but combinations are not allowed. (In other words, a single group of 7 cannot contain both violet and blue, green and orange, etc., pixels.)
  • For any given pixel to be colored black onscreen, at least one bit adjacent to the bit in memory that represents it must also be black. (In other words, a black vertical line like a white vertical line must always be at least 2 pixels wide.)

With all that in mind (and yes, I know it hurts), we realize it’s perhaps more accurate to say that the Apple II has a horizontal resolution of just 140 pixels, since each pixel’s color is controlled so thoroughly by the pixel adjacent to it. And given that combined with what a royal bitch the hi-res mode was to work with for programmers, it’s worth asking whether this whole baroque scheme is really worth the headache. Woz’s tendency to produce stuff like this in the name of efficiency is one of the more problematic aspects of a generally brilliant engineer. (Remember, Atari had to redo Woz’s Breakout design because no one else could figure it out. This fact, legendary as it has become as a sort of proof of Woz’s genius, might reflect more poorly on him than it does on Atari’s engineers from a certain point of view…) Have a look at the image above once again. Notice how the vertical lines are all in green or violet, while the horizontals are in white? Ken could only have made those vertical lines white by doubling their thickness, and throwing all of the proportions off. The Apple II literally does not permit the simple black-and-white sketches he really wants to display. Crazy stuff, huh?

These odd patterns of coloration, not to mention the distinctive pastel tones of the colors themselves, make an Apple II display, then as well as now, instantly recognizable to anyone who’s spent any time at all with one. While its display is unusually idiosyncratic, the Apple II is by no means alone here. Displays from most early microcomputers exhibit telltale traces of their origin. It’s one of the things that make these old machines so appealing to some living in our modern world of anonymous technological perfection. Call it personality, or, if you must, call it soul.

Which doesn’t, of course, mean that contemporary users didn’t struggle like mad to find ways to overcome basic limitations like these. More on that later. But next time, we’ll see how Mystery House actually plays as a game, and ask what it means in historical context.

 
 

Tags: , ,

Ken and Roberta

There are two prototypical kinds of “computer professionals” in the world. First there are the purist hackers, who dive into the depths of circuits, operating systems, and programming languages like explorers discovering new lands; it wasn’t by chance that away from the computer Will Crowther was a caver, nor that he now spends his time deep-sea scuba diving. For the purists the reward is in the thing itself, in learning to understand and navigate this binary wonderland and maybe, just maybe, someday making (or helping to make) something really, truly new and cool. The other group is made up of the careerists. These people end up in the field for some mixture of a variety of reasons: because they need to earn a good living to support their family (no shame in that); because they’ve heard computers are cool and the next big thing (hello, Internet bubble); because they have a vision of society which requires computers as its enabler (hello, Steve Jobs); because they just want to get really, really rich (why, there’s Steve again hiding out in the corner hoping not to be noticed — hi!). One thing only binds this disparate group together: they are attracted to computers not by their intrinsic interest in the machines themselves but by externalities, by a vision of what the machines can do, whether for them or for others. The two groups often seem — and believe themselves to be — at odds with one another, but in truth they need each other. Witness the dynamic duo of Woz and Jobs that built the Apple II and got it to the masses. Or witness Ken and Roberta Williams, the power couple of 1980s adventure gaming.

Ken and Roberta married in 1972. He was just 18 at the time; she was 19. He was attending California Polytechnic Pomona University as a physics major, and failing; she was living at home and not doing much of anything. Contrary to what you might be thinking, there was no shotgun involved. He simply wanted Roberta in his life and was determined to have her there, permanently. Steven Levy writes that his words to her were simply, “We’re getting married, and that’s it.” She “didn’t fight it.” Right there you learn a lot about their two personalities.

Within a year or so of their marriage Ken, a restless, driven, somewhat aggressive young man with no real respect for or interest in higher education with its hierarchical structure and its abstract theorizing, could see he wasn’t going to make it as a physics major, much less a physicist. Roberta, meanwhile, was now pregnant. Ken needed a career, and he needed one quick.

In the early 1970s the institutional computer industry was nearing its peak, supplying mainframes and minicomputers by the thousands to businesses, universities, public and private schools, branches of government, and research installations. We’ve met several of the prominent companies already (IBM, DEC, HP), each serving their own core sectors of this huge market while competing with one another on the margins. Another was Control Data Corporation. Founded in 1957 by a group of refugees from an even earlier company, Sperry, CDC had by the early 1970s carved out a reputation for itself as a manufacturer of prestigious and expensive supercomputers of the type used for some of the most intensive scientific computing. The supercomputer market was, however, a small one, and so the bulk of CDC’s business was courtesy of its line of more plebeian mainframes that competed directly with IBM for corporate business. To carve out a place for itself against the larger company, CDC tried to stick to a “10% rule”: to make sure each of its systems was always 10% faster and 10% cheaper than the nearest equivalent IBM model. For a number of years this approach was very good to CDC, sufficiently so that the company opened a little trade school all its own to train future custodians of its systems. Armed with a $1500 student loan co-signed by a very concerned father-in-law, Ken entered Control Data Institute. In doing so he was conforming to a stereotype that remains with the computer industry to this day: the pure hackers go to universities and get computer-science degrees; the careerists go to trade schools and get certificates in something “practical.”

Indeed, the atmosphere at Control Data Institute promised nothing like the free-wheeling intellectual exploration of the computer-science labs at MIT or Berkeley. The emphasis was on pounding in the rote tasks and procedures needed to maintain and run the big, batch-processing mainframes of CDC at the banks and other large bureaucratic entities that housed them. And that suited Ken, hungry for a career in business, just fine. Where an MIT hacker might have seen intolerable drudgery, he saw money to be made. When he turned out to be pretty good at this computer stuff — even within limits to enjoy it — that just increased the earning potential.

After finishing at CDC, Ken spent the rest of the 1970s living a life that we more typically associate with the following decade, bouncing from company to company in search of ever better salaries while generally also juggling two or three independent consulting gigs on the side. With computers still mysterious, almost occult objects to most people, a fast-talking, energetic, and ambitious young man like Ken could go far with just the modicum of knowledge he had gained at CDC. As that knowledge increased and he became an ever better programmer and problem solver courtesy of the best teacher of all, experience, he seemed even more of a miracle worker, and found himself even more in demand. Ken, in other words, was becoming a pretty damn good hacker almost in spite of himself. But he always wanted more — a new hot tub, a bigger house, a nicer car, a place in the country — even as he dreamed of retiring young and bequeathing a fortune to his children. (These things would in fact happen, although not in the way Ken thought they would in the 1970s.) Ken made no apologies for his materialism. “I guess greed,” he later told Levy, “would summarize me better than anything. I always want more.”

When the first kit computers that one could build in one’s home appeared in 1975, Ken barely noticed. There was no real money to be made in them, he believed, unlike his big, boring mainframes. When the trinity of 1977 marked the arrival of a PC you didn’t need a soldering iron to assemble, he likewise paid no attention. It was not until a couple of years later that the beginning of a real, paying market in professional business software, exemplified by pioneering applications like VisiCalc and WordStar, made Ken begin to pay attention to the little “toy” machines. When he finally bought an Apple II in January of 1980, it was for a very specific purpose.

At the time there were only two real language possibilities for Apple programmers: they could use BASIC, which was easy to learn and get started with but quickly became a nightmare when trying to structure large, complex programs; or assembly language, which gave the ultimate in precise control over the hardware but was well-nigh impenetrable for the uninitiated, tedious in the micro-management it required, and just as bereft of structure. Ken saw an opportunity for a more sophisticated high-level language, one designed to be used by serious programmers creating complex software. Specifically, he wanted to bring FORTRAN, as it happens the implementation language of the original Adventure (not that Ken likely knew this or cared), to the little Apple II. With that purpose in mind, he registered a company of his own, choosing to call it On-Line Systems, a name fairly typical of the vaguely futuristic, vaguely compound, but essentially meaningless names (Microsoft, anyone?) that were so common in the era.

And what was Roberta doing during these years? Well, she was raising the Williams’ two children and happily (at least to external observers) playing the role of housewife and homemaker. She had always been a painfully shy, passive personality who by her own admission “could hardly make a phone call.” If Ken seemed to already be living in the frenetic 1980s rather than the mellow 1970s, Roberta seemed a better match for the 1950s, the doting wife who took care of the children, made sure everyone in the family had a good breakfast, lunch, and dinner, and meekly entrusted the big decisions and the earning of a living to the man of the house. That makes what happened next doubly surprising.

Shortly before Ken bought that first Apple, and while the Williams’ second son was just eight months old, Ken happened to have a remote terminal at the house for one of his gigs. The mainframe to which it could connect had on it a copy of Adventure, which by now had been ported to a variety of other platforms beyond the PDP-10. Ken called Roberta over to have a look at what he regarded as nothing more than a curiosity. Roberta, however, was immediately transfixed. “I started playing and kept playing it. I had a baby at the time, Chris was eight months old; I totally ignored him. I didn’t want to be bothered. I didn’t want to stop and make dinner.” As Ken wondered what had become of his dutiful wife, Roberta stayed up most of the night playing, then lay awake in bed working through the puzzles in her mind. It was no doubt a relief to everyone when she finally finished the game after a month of effort.

But the respite didn’t last long. After Ken brought the Apple II into the home, it didn’t take Roberta long to learn about the works of Scott Adams. Soon she was back to obsessively playing again. But then another thought began to crowd out the conundrums of the games: what if she could make a text adventure of her own? She was turning the most inspirational corner I know, imagining herself as a creator rather than a passive consumer. Inspired mostly by Agatha Christie’s novel Ten Little Indians and the board game Clue, she began to sketch ideas for a text adventure as cozy murder mystery, a genre that the form had not yet tackled. When she was pretty far along, she took a deep breath and laid out her ideas to Ken.

The story concept was certainly innovative, but it wasn’t the sort of innovation that would immediately appeal to a guy like Ken, with little interest in game design in the abstract. He was rather interested in products he could sell, operating intuitively by a rule he would later, for better and perhaps sometimes for worse, codify and articulate regularly: “Games have to have ‘WOW-value.’ If you don’t say ‘wow’ when someone describes the game to you, or you see it from 10 feet away, there’s no reason to market the game.” At first, caught up in his FORTRAN software and his prior experience of computers only as serious tools of business, he was dismissive of Roberta’s little project. But as she persisted, and as he perhaps began to notice that companies like Adventure International were growing rapidly and making real money just like the “serious” software houses, he began to reconsider. Still, he needed something special, needed an angle to help their little game stand out from the likes of the established line of Scott Adams games.

He began to think about the Apple II, with its comparatively cavernous 48 K of RAM, its fast and reliable disk drives, and its bitmap graphics capability. What if he designed their game around the unique capabilities of that machine, instead of taking the portable lowest-common-denominator approach of Adams? And then came the brainstorm: he could use the Apple’s hi-res mode to include pictures with the text. That would certainly make their game stand out. Pretty soon FORTRAN was forgotten, and work on Mystery House (the first of a whole line of On-Line Systems “Hi-Res Adventures”) had begun in earnest. The husband-and-wife team were not that far removed from Woz and Jobs. Here, Roberta designed the thing out of her inherent fascination with the thing itself, while Ken enabled her efforts, providing the tools and support she needed to bring her vision to life and, soon enough, finding ways to sell that vision to the masses.

 
 

Tags: , ,

Eamon, Part 2

One of the ironies of Eamon is that it reached its greatest aesthetic heights and greatest popularity long after its creator, Donald Brown, had abandoned it. For much in this blog entry I’m therefore indebted to the man who followed Brown as the head of the Eamon community, another Des Moines resident by the name of John Nelson. The reconstruction that follows is the best I’ve been able to do from Nelson’s memories and the other available documentation, but there is much about Eamon‘s history that remains sketchy or even contradictory.

Nelson first discovered Eamon in very early 1980, when he visited the home of an early player to trade comic books. At that time, there were just four additional adventures available beyond the base disk. By the time he bought his first Apple II from the Computer Emporium (no small investment at some $2500; Nelson had to sell his car to manage it), the collection was already up to ten. He met Brown himself at the Computer Emporium while making the purchase, and got from him the full set. In these early days Eamon saw little if any distribution beyond the circle of employees, customers, and hangers-on around the Computer Emporium. Most adventures were written either by Brown himself or by his immediate circle of friends; Jim Jacobson, Computer Emporium employee and author of “The Zephyr Riverventure,” was particularly prolific. That’s little surprise considering that in these earliest days creating an Eamon adventure was a tricky, undocumented process bereft of the tools and documentation that would come along later. Presumably, one virtually had to be in direct communication with Brown to have a chance of pulling it off.

That began to change when Brown released the first edition of the Dungeon Designer Diskette, a collection of utilities and information designed to at least begin to explain and automate the process. Still, it was only a beginning; the tools were still in a very primitive state. As the included Manual for Eamon Dungeon Designers attests, the programmer even had to do her own word wrapping when writing room descriptions: “If your description is longer than 40 characters, you must pad it with spaces so that when the description wraps around the Apple’s 40-column screen, the breaks are between words.” Further, Nelson describes Brown’s tools as prone to crashes and data corruption of all stripes. Nelson soon set to work improving these tools, if initially only for his own use, and making adventures: numbers 15, 16, 19, and 20 are all his work.

Up to this point Brown had been taking an active role in curating Eamon‘s growing library of adventures, testing each and, once it was judged ready, assigning it an official number in the collection and creating a disk for distribution from the Computer Emporium. But in 1981 Brown’s friends at the Computer Emporium decided that they had the talent to do more than just sell software and hardware; they would become software developers in their own right. They therefore formed CE Software (get it?), with the initial intention of concentrating on games. Given the hit that Eamon had become in the store, they asked Brown to come work with them on this new venture.

The result was SwordThrust, a commercial version of the Eamon concept. Just like Eamon, SwordThrust consisted of a master disk and a series of scenario disks through which the player was expected to guide the same character. The difference, beyond considerable additional complexity and refinement, was of course that the player had to pay for the privilege each time. Brown and CE gave SwordThrust a good hard try, releasing six adventures in addition to the base system, but the public just wasn’t interested in paying for an RPG system that looked like a text adventure. In 1982 CE pulled the plug, not only on SwordThrust but on all of its game-development efforts. But never fear, the story has a happy ending of sorts: CE and Brown went into productivity applications instead, and had a long and successful run there, most notably as the developers of QuickMail and QuicKeys for the Macintosh. In fact, CE Software is still alive today, long after the Computer Emporium closed its doors, under the name Startly Technologies.

But where did SwordThrust leave Eamon? That, as it happens, is exactly the question Nelson found himself asking when he saw Brown turning away from his first creation. He asked Brown if he could assume the role of Eamon‘s curator, to continue to verify and catalog new adventures and keep the system alive. Brown said okay.

Still, with its creator having abandoned it, there followed a fallow period for Eamon; by late 1982 the adventure count had risen to just 25. But then Nelson found a way to get the system some national exposure. In his own words:

About this time, an article appeared in Creative Computing magazine written by Robert Plamondon. He was lamenting about the lack of any really good text adventure systems for the Apple II computer. I contacted Robert and asked if he had ever heard of Eamon. He had not, but was interested. I sent him several of the diskettes and he was very happy with them. He asked if he could include me in a follow-up article about Eamon. I said sure, no problem. So a follow-up article appeared in Creative Computing and I started getting mail from people all over the world.

In a very real way that article, which appeared in the January 1983 issue of Creative Computing, marked a rebirth for Eamon. Word began to spread through user groups and electronic bulletin-board systems around the world, with Nelson serving as the central hub for cataloging and distribution. Encouraged by the new interest, Nelson founded the National Eamon User’s Club with a friend of his, Bob Davis. They published the first NEUC newsletter in March of 1984, which among other things served as a godsend for the writers of articles like this one; from this point forward we at last have ongoing documentation of events in the world of Eamon. By that time Eamon had already grown to some 50 adventures.

Nelson is in many ways the unsung hero of Eamon. In addition to curating and popularizing, he also did critical technical work, building from Brown’s buggy utilities a workable and properly documented Dungeon Designer’s Disk and implementing plenty of improvements to the core Eamon system itself. When his interest in the Apple II began to wane in the late 1980s, he began work on a new Eamon for the IBM PC which ultimately never came to fruition, and passed the NEUC and its newsletter to a particularly active club member named Tom Zuchowski. Zuchowski changed the name of the club to the Eamon Adventurer’s Guild but otherwise pretty much continued business as usual. By this point, early 1988, there were 155 adventures available through the club.

The years of Nelson’s NEUC newsletter, 1984 to 1987, appear to represent the very peak of Eamon activity. In the years that followed, interest and production slowly tailed off, mirroring the declining fortunes of the Apple II platform itself. Zuchowski published the last regular issue of his newsletter in January of 2001, at which time Eamon was approaching 250 adventures. There has been sporadic activity since then — one Wade Clarke even entered a new Eamon adventure in last year’s IF Competition — but for all essential purposes this event marks the end of Eamon‘s long run as a living system.

Even at its peak Eamon was always something of a semi-obscure oddity, seldom mentioned even in adventure-gaming circles. When Nelson turned the NEUC over to Zuchowski, there were 138 active, dues-paying members. It’s of course true that this number represents only the very hardcore, and that many times that number likely played Eamon from time to time on a casual basis. Still, by any measure Eamon‘s presence was a pretty small one in comparison with the gaming scene of the Apple II as a whole. What they lacked in numbers, however, they made up for in enthusiasm and a sheer bloody-minded determination to keep the system alive even as the platform on which it ran fell into obsolescence.

The approach to the text adventure that Eamon pioneered, replacing RPG-style combat and simulation for set-piece puzzle design, has generally garnered little acceptance outside the Eamon community, excepting the oeuvre of the late Paul Allen Panks. Indeed, for many years “randomized combat” was practically a synonym for terrible game design in IF circles. As I mentioned in my first post in this series, though, some thoughtful folks have recently been challenging that convention wisdom. Certainly the newer IF-development systems have already begun to allow more simulation-oriented storyworlds that replace some aspects of set-piece design with believable emergent challenges. And certainly the hundreds or thousands of people who have been hooked by Eamon over the years saw something there that even the well-respected works of companies like Infocom just weren’t giving them. How all of these factors will play out in the long run is, as always, yet to be determined. For now, I’ll just say that, much as I love and respect Infocom, it never hurts to consider how some other folks approached the art of the text adventure as well if you’re looking for ideas to draw from.

Eamon is also of great interest for being at the center of the first community of interest to form not just around playing ludic narratives but around creating them. This fact, showing as it does how a small but committed community could create impressive technology and impressive interactive art, may be the most important aspect of Eamon of all. We’ll be meeting quite a few heirs to its tradition later on in this blog.

But next up, we start down a slippery slope indeed, as graphics come to the text adventure for the first time.

 
14 Comments

Posted by on September 25, 2011 in Digital Antiquaria, Interactive Fiction

 

Tags: ,

A Journey into the Wonderful World of Eamon

Would you like to tag along with me on an actual Eamon adventure, to see how it really plays? Of course you would!

Eamon consists of a collection of BASIC programs spliced together with virtual duct tape and bailing wire. It’s an ingenious design given the limitations of a BASIC implementation running on an 8-bit computer, if also a bit horrifying to modern sensibilities of proper programming practice. Its structure is in fact strongly reminiscent of another early BASIC RPG we looked at not too long ago, Temple of Apshai.

All of the utilities on the Eamon master disk build a narrative frame around their rather prosaic functionality. When we boot up, the first scene that greets us is a hall of administration. (Yes, it seems that bureaucracy is alive and well even in the realms of fantasy.)

The Wonderful World of Eamon

If we fail to go to the desk as instructed, the results are unfortunate. Here we see the first example of the disconcerting glee Donald Brown takes in killing off his players in the most arbitrary fashion. Just imagine what sort of tabletop dungeon master this guy would have made…

All of our current living characters are stored in a data file on the master list. If we follow instructions this time, we can choose one of them from the guild hall by simply entering a name.

If the name we enter is not in our current stable of adventurers, we get the opportunity to create a new character. A second BASIC program (“New Adventurer”) gets loaded in, and we’re off.

While Eamon‘s Dungeons and Dragons heritage is never less than obvious, its rules are not a slavish recreation of that system, if only because the technical realities of a 48 K computer make some serious simplification de rigueur. Case in point: the complexities of D&D characters are reduced to three randomly generated attribute scores, hardiness, agility, and charisma.

Eamon character creation utility

The system does not allow the player to have any role in the creation of her character beyond choosing a name and a sex. Three unlucky “die rolls” can leave her with an untenable character, and even a lucky roll or two in the wrong place can leave her with a character she’s just not interested in playing. Similar problems quickly led to new house rules — and, eventually, official rules — for character creation in D&D, attempting to mitigate the effects of luck and give the player more opportunity to exercise choice at this critical juncture that could define the player’s experience for days, weeks, or months of play to come. Similarly if more simply, one of the first common Eamon add-on programs was the morbidly named but useful “suicide” utility that let the player blow up a weak or otherwise unacceptable character and try again.

Whether we create a new character or play with an existing one, our character gets removed from the main characters file and placed in one that holds just the currently active character (“The Adventurer”). After the obligatory nerdy Star Trek reference, a third BASIC program starts up, “Main Hall.” It reads in “The Adventurer” (having each stage leave a data file lying around is the only practical way to get all of these programs to talk to one another), and we find ourselves in Eamon‘s main utility program, once again disguised as a fiction of its own.

Unlike Temple of Apshai, Eamon does have a rudimentary magic system consisting of four spells: blast, heal, speed, and power. The first three work as you might expect; the last is a rather ingenious cop-out, doing whatever the designer of a particular adventure decides it should do.

The “Main Hall” does have one unfortunate character, Shylock the banker.

I’m willing to give Brown a pass here, just because I don’t think he had a clue what sort of historical and cultural baggage his Shylock was toting behind him. And if one must crib antisemitism from someone, I can think of several worse people to draw from than Shakespeare. Anyway, let’s choose option 1 and go adventuring, shall we?

We’ll start, like aspiring Eamon players for time immemorial, with the adventure included on the master disk, Brown’s own “Beginners Cave.”

As you might expect, this is the most complicated part of Eamon. Just before “Main Hall” requests a scenario disk it deletes the player’s character from the master disk entirely. When the player inserts the scenario disk, her current character is written out to the optimistically titled “Fresh Meat” data file. The program then looks to another data file that should be present on the scenario disk, “Eamon.name,” for the name of yet another BASIC program to run; this constitutes the actual adventure. Brown and later Eamon maintainers provided a starting framework for this program, representing the first consciously designed reusable adventuring engine to be made available for general use. In its stock form, it lets the player navigate around a network of rooms (whose connections and contents are stored in “Eamon.rooms,” whose names are stored in “Eamon.room names,” and whose descriptions are stored in “Eamon.descriptions”); to fight monsters (whose attributes are defined in “Eamon.monsters”); and to pick up objects (described in “Eamon.artifacts”). The latter, in a zenlike simplification, can be worthwhile either as treasures (good for gold back at the main hall) or weapons (good for bashing monsters in scenarios as well as gold at the main hall). Brown provided utilities for populating these data files appropriately, but doing so could obviously yield only a very basic (no pun intended) adventure. To build more complicated interactions, to (to choose an example from Brown’s documentation) make a sword that teleports its owner to a random room at random times, the designer must modify the BASIC code of the starting framework itself. The result is infinite possibility of a sort, if a rather ugly way of achieving same; Brown imagined such scenarios as an Eamon adventure where “you are leading an army into battle, with morale affected by your charisma!”

But today we’re just going on a simple sort of Eamon adventure.

In my first post about Eamon, I called it a CRPG masquerading as a text adventure. That impression becomes all the more pronounced if we type something — and it’s not hard to do — that the simple two-word parser doesn’t understand. We get a list of all available commands in this adventure.

That’s something you’ll seldom see in a more traditional text adventure. It says something about Brown’s focus; he’s interested in the parser only as a means of getting commands into his program, judging it a better tool for that purpose than menus given the limited memory and screen real estate he has to work with. There’s a comparison to be made here to Robert Lafore’s “interactive fiction” games, which are really Choose-Your-Own Adventure-style choice-based narratives masquerading as text adventures. The focus of early Eamon is firmly on character building and monster bashing, not puzzle solving. Its resemblance to Adventure and the Scott Adams efforts is more an accident of history than a sign of similar intent. On the positive side, that means that guess-the-verb problems and other classic old-school parser frustrations are largely absent in Eamon. Perhaps, depending on your predilections, less positively, most attempts to depart from moving about and hitting things yield little result.

When “Beginners Cave” does try to get more ambitious, the results often leave you wishing it hadn’t. At one point you come upon a sinister, glowing book. If this happened in a tabletop D&D session, or even in a modern CRPG, you would have a variety of tools with which to investigate: perhaps a “detect magic” or “detect evil” spell, or a trip to the friendly local high-level mage. Here, though, we have only two options: just to recklessly read the thing or to leave it alone and wonder forever what it might be. If we read it, the worst quickly happens:

And so we have here yet another example of an early ludic narrative wanting to indulge in storytelling possibilities (similar mysterious artifacts being a staple of D&D adventures) that its underlying technology just cannot yet support, resulting in the worst kind of unfairness.

Similarly, “winning” in “Beginners Cave” requires us to discover a secret passage by typing EXAMINE in just the right location.

When we do so, we find a secret temple, and learn that our previously unstated goal was apparently to rescue “Duke Luxom’s not-too-bright daughter.” Ah, well, what would a quest be without a princess (or… what’s a duchess called before she becomes a duchess?) to rescue?

If we survive to return to the exit, our character is copied back over to the main disk, complete with whatever attribute improvements experience brought to him and whatever loot he picked up. If he doesn’t survive, he’s lost forever — remember, he got deleted from the master disk before we started the adventure.

I also recently played through a couple of other very early Eamon adventures: “The Zephyr Riverventure” (Adventure #4), by an employee at the Computer Emporium, Jim Jacobson; and “The Death Star” (Adventure #6), again by Brown himself. Both are much larger than “Beginners Cave,” but provide a similar mix of mapping, combat, and the occasional sudden death to keep everyone on their toes. “Riverventure” seems inspired by a movie of the time, Apocalypse Now.

“The Death Star” is based on the same middle act of Star Wars that inspired Dog Star Adventure, and is interesting as the first Eamon adventure to push the system into another milieu entirely.

I’m most interested, at least for now, in understanding Eamon‘s place in the early history of computerized ludic narrative; thus the attention I give here to these very early incarnations of the system. It’s only fair to note, however, that the sophistication of many later Eamon adventures was vastly greater than that of these early efforts. What I say here should by no means be taken as the last word on the system.

That said, there are certain problematic aspects that are endemic to the system, even if we leave aside its core focus on randomized combat that usually comes down to watching the roll of virtual dice and hoping for the best. In having players take their characters through a series of adventures, Brown clearly hoped to duplicate the feel of a classic D&D campaign, in which players play the same characters through a whole series of exploits, growing in power all the while, until retirement or death overtake them. In Eamon, though, death is too often capricious, coming at the whim of a designer. The dangers of combat are perhaps less problematic, but Eamon adventures were graded by difficulty in only the most cursory way, perhaps because, in the absence of defined character levels in Eamon, a consistent grading system was hard to devise. Small wonder that programs to “cheat,” to back up or resurrect characters, were soon included on the master disk itself. Such programs may ease considerable player pain, but they also of course to some extent pull against the core vision of Eamon itself.

I plan to finish this series off with the story of Eamon‘s post-Brown years very soon. If you would like to experience the system for yourself, the Eamon Adventurer’s Guild website is the best place to start. Here you’ll find disk images of all Eamon adventures that you can load using an Apple II emulator.

 
17 Comments

Posted by on September 24, 2011 in Digital Antiquaria, Interactive Fiction

 

Tags: ,

Eamon, Part 1

Videogames today can almost all be slotted into one of a collection of relatively stable genres: first-person shooter, real-time-strategy game, point-and-click adventure, action RPG, text adventure, etc. Occasionally a completely original game comes along to effectively carve out a whole new genre, as happened with Diner Dash and the time-management genre respectively in the mid-2000s, but then the variations, refinements, and outright clones follow, and things stabilize once again. One of the things that makes studying the very early days of gaming so interesting, though, is that genres existed in only the haziest sense; everyone was pretty much making it up as they went along, resulting in gameplay juxtapositions that seem odd at first to modern sensibilities. Still, sometimes these experiments can surprise us with how effectively they can work, even make us wonder whether today’s genre-bound game designers haven’t lost a precious sort of freedom. A case in point: Eamon, which used the interface mechanics of the text adventure but largely replaced puzzle-solving with combat, and also inserted an idea taken from Dungeons and Dragons, that of the extended campaign in which the player guides a single evolving character through a whole series of individual adventures.

As an actively going concern for more than twenty years and a system that still sees an occasional trickle of new activity, Eamon is one of the oddest and, in its way, most inspiring stories in gaming history. For such a long-lived system, its early history is surprisingly obscure today, largely because the man who created Eamon, Donald Brown, has for reasons of his own refused to talk about it for nearly thirty years. I respected his oft-repeated wish to just be left alone as I was preparing this post, but I did make contact with another who was there almost from the beginning and who played a substantial role in Eamon‘s evolution: John Nelson, who took over development work on the system after Brown and founded the National Eamon User’s Club. Through Nelson as well as through my usual digging up of every scrap of documented history I could find, I was able to lift the fog of obscurity at least a little.

But before we get to that I should tell you what Eamon was and how it worked. Though there have been a handful of attempts to port it to other machines, Eamon had its most popular incarnation by far on the computer on which Brown first created it, the Apple II. The heart of the system was the “Master Diskette,” containing a character-creation utility; a shop for weapons, armor, and spells; a bank for storing gold between adventures; and the first simple adventure, the “Beginner’s Cave.” This master disk was also the springboard for many more adventures, which number more than 250 at this writing. While each of these has many of the characteristics of a free-standing text adventure, there are two huge differences that separate them from the likes of the Scott Adams games: the player imports her own character to play with, with her own attribute scores and equipment; and they mostly replace set-piece puzzles with the tactical dilemmas of simulated combat. On my little continuum of simulation versus set-piece design, in other words, Eamon adventures fall much further to the left than even old-school text adventures, near the spot occupied by old-school RPGs.

To modern sensibilities, then, Eamon adventures are CRPGs disguised as text adventures.

Indeed, the design of Eamon bears the influence of D&D everywhere. The idea of a long-term “campaign” involving the same ever-evolving character comes from there, as does the focus on combat at the expense of more cerebral challenges. In these ways and others it is actually quite similar to Automated Simulations’s Dunjonquest series, of which Temple of Apshai was the first entry. (The Dunjonquest system was also advertised as an umbrella system of rules for which the player bought scenarios to play, just as she bought adventure modules for her tabletop D&D campaign.) Brown is clearly more interested in recreating the experience of an ongoing D&D campaign on the computer than he is in the self-contained storytelling of what has evolved into modern interactive fiction. As such, it represents a fascinating example of a road not taken. (Until recently, perhaps; S. John Ross and Victor Gijsbers have recently been experimenting with the possibilities for tactical combat in IF once again, with results that might surprise you. Notably, both men came to IF from the world of the tabletop RPG.)

Yet Eamon also represents the origin of a road most decidedly taken, one that stretches right up to the present day. It is the first system created specifically for the creation of text adventures. All those who, to paraphrase Robert Wyatt, couldn’t understand why others just play them instead of writing them themselves now had a creative tool for doing just that. It may seem odd to picture Eamon as the forefather of Inform 7 and TADS 3, but that’s exactly what it is. In fact, it is the first game-creation utility of any type to be distributed to the computing public at large.

Brown was a student at Drake University in Des Moines at the time that he created Eamon. While a couple of yearbook photos show him peeking out from the back row of his dorm house’s group pictures, he looks like a fish out of water amongst the other party-hardy types. He receives nary an additional mention in either yearbook, and didn’t even bother to pose for an individual picture. It’s doubtful that he ever graduated. Clearly, Brown’s interests were elsewhere — in two other places, actually.

His father purchased an Apple II very early. Brown was instantly hooked, devoting many hours to exploring the possibilities offered by the little machine. Soon after, a fellow named Richard Skeie started a new store in Des Moines called the Computer Emporium. The CE went beyond merely selling hardware and software, hosting a computer club that met very frequently at the shop itself, and thus becoming a social nexus for early Des Moines microcomputer (particularly Apple II) enthusiasts. Brown was soon spending lots of time there, discussing projects and possibilities, trading software, and socializing amongst peers who shared his geeky obsession with technology.

The other influence that would result in Eamon stemmed from the tabletop wargame and RPG culture that was so peculiarly strong in the American Midwest. Through an older friend named Bill Fesselmeyer, Brown plunged deeply into Dungeons and Dragons. But Fesselmeyer — and, soon enough, Brown — took his medieval fantasies beyond the tabletop, via the Society for Creative Anachronism.

Born out of a spontaneous “protest against the twentieth century” at Berkeley University in 1966, the SCA is a highly structured club — or, some would say, lifestyle — dedicated to reliving the Middle Ages. Still very much alive today, it has included in its ranks such figures as the fantasy authors Diana Paxson (the closest thing it has to a founder) and Marion Zimmer Bradley. From the club’s website:

The Society for Creative Anachronism, or SCA, is an international organization dedicated to researching and re-creating the arts, skills, and traditions of pre-17th-century Europe.

Members of the SCA study and take part in a variety of activities, including combat, archery, equestrian activities, costuming, cooking, metalwork, woodworking, music, dance, calligraphy, fiber arts, and much more. If it was done in the Middle Ages or Renaissance, odds are you’ll find someone in the SCA interested in recreating it.

What makes the SCA different from a Humanities 101 class is the active participation in the learning process. To learn about the clothing of the period, you research it, then sew and wear it yourself. To learn about combat, you put on armor (which you may have built yourself) and learn how to defeat your opponent. To learn brewing, you make (and sample!) your own wines, meads and beers.

That introduction emphasizes the “historical recreation” aspect of the SCA, but one senses that its role-playing element is an equal part of its appeal, and the aspect that most attracted D&D fans like Fesselmeyer and Brown. The SCA’s idea of club organization is to divide North America into “kingdoms,” each ruled by a king and queen. From these heights descend a web of barons and dukes, shires and strongholds. Each member chooses a medieval name and many craft an elaborate fictional persona, coat of arms included. The king and queen of each kingdom are chosen by clash of arms in a grand Crown Tournament. Indeed, chivalrous clashes are much of what the SCA is about; John Nelson told me of stopping by Brown’s house one day to find him and Fesselmeyer “sword fighting in the living room.” There is much about the SCA that resembles an extremely long-term example of the modern genre of live-action role-playing games (LARPs), a genre which itself grew largely out of the tabletop RPG tradition. It’s thus little surprise that Fesselmeyer, Brown, and many other D&D fans found the SCA equally compelling; certainly a large percentage of the latter were also involved in the former, especially in the gaming hotbed that was the Midwest of the 1970s.

If Brown is the father of Eamon, Fesselmeyer (who died in a car crash on his way to an SCA coronation in 1984) is its godfather, for it was he who pushed Brown to combine his interests into a system for role-playing on the computer. Brown likely began distributing Eamon out of the Computer Emporium at some point during the latter half of 1979. From the beginning, he placed Eamon into the public domain; the CE “sold” Eamon and its scenario disks for the cost of the media they were stored on.

In practice, the Eamon concept proved to be both exciting and problematic. I’ll get to that next time, when I look more closely at how Eamon is put together and how a few early adventures actually play.

 
15 Comments

Posted by on September 18, 2011 in Digital Antiquaria, Interactive Fiction

 

Tags: ,