RSS

Monthly Archives: September 2011

IF History on a Kindle (or other e-reader of your choice)

Ever since I first put Let’s Tell a Story Together online over five years ago, people have periodically asked me to make it available in some more convenient reading format. At those times I’ve generally nodded along in agreement, promised to get on that real soon now, and then promptly done nothing at all about it. Well, my strategy of infinite procrastination has finally begun to pay off: someone’s gotten frustrated enough with me to do something about it for me. Rick Reynolds has created versions that you can read using your real or virtual e-reader. If you have a Kindle, you’ll want the .mobi version. If you have something else, the .epub version is for you.

My warmest thanks go to Rick for this totally unsolicited act of kindness.

 
3 Comments

Posted by on September 26, 2011 in Interactive Fiction, Modern Times

 

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

The Apple II

Steve Jobs’s unique sense of design and aesthetics has dominated every technology project he’s led following the Apple II — for better (the modern Macintosh, the iPhone, the iPod, the iPad) or worse (the Apple III) or somewhere in between (the original 1984 Macintosh, the NeXT workstations). The Apple II, though, was different. While Jobs’s stamp was all over it, so too was the stamp of another, very different personality: Steve Wozniak. The Apple II was a sort of dream machine, a product genuinely capable of being very different things to different people, for it unified Woz’s hackerish dedication to efficiency, openness, and possibility with Jobs’s gift for crafting elegant experiences for ordinary end users. The two visions it housed would soon begin to pull violently against one another, at Apple as in the computer industry as a whole, but for this moment in time, in this machine only, they found a perfect balance.

To call Jobs a mediocre engineer is probably giving him too much credit; the internals of the Apple II were all Woz. Steven Levy describes his motivation to build it:

It was the fertile atmosphere of Homebrew that guided Steve Wozniak through the incubation of the Apple II. The exchange of information, the access to esoteric technical hints, the swirling creative energy, and the chance to blow everybody’s mind with a well-hacked design or program… these were the incentives which only increased the intense desire Steve Wozniak already had: to build the kind of computer he wanted to play with. Computing was the boundary of his desires; he was not haunted by visions of riches and fame, nor was he obsessed by dreams of a world of end users exposed to computers.

When you open an Apple II, you see a lot of slots and a lot of empty space.

All those slots were key to Woz’s vision of the machine as a hacker’s ultimate plaything; each was an invitation to extend it in some interesting way. Predictably, Jobs was nonplussed by Woz’s insistence on devoting all that space to theoretical future possibilities, as this did not jibe at all with his vision of the Apple II as a seamless piece of consumer electronics to be simply plugged in and used. Surely one or two slots is more than sufficient, he bargained. Normally Jobs, by far the more forceful personality of the two, inevitably won disputes like this — but this time Woz uncharacteristically held his ground and got his slots.

Lucky that he did, too. Within months hackers, third-party companies, and Apple itself began finding ways to fill all of those slots — with sound boards, 80-column video boards, hard-disk and printer interfaces, modems, co-processor and accelerator cards, mouse interfaces, higher resolution graphics boards, video and audio digitizers, ad infinitum. The slots, combined with Woz’s dogged insistence that every technical nuance of his design be meticulously documented for the benefit of hackers everywhere, transformed the Apple II from a single, static machine into a dynamic engine of possibility. They are the one feature that, more than anything else, distinguished the Apple II from its contemporaries the PET and TRS-80, and allowed it to outlive those machines by a decade. Within months of the Apple II’s release, even Jobs would have reason to thank Woz for their existence.

All of the trinity of 1977 initially relied on cassette tapes for storage. Both the PET and TRS-80 in fact came with cassette drives as standard equipment, while the Apple II included only a cassette interface, to which the user was expected to connect her own tape player. A few months’ experience with this storage method, the very definition of balky, slow, and deeply unreliable, convinced everyone that something better was needed if these new machines were to progress beyond being techie toys and become useful for any sort of serious work. The obvious solution was the 5 1/4 inch floppy-disk technology recently devised by a small company called Shugart Associates. Woz soon set to work, coming up with a final design that engineers who understand such things still regard with reverence for its simplicity, reliability, and efficiency. The product, known as the Disk II, arrived to market in mid-1978 for about $600, vastly increasing the usability and utility of the Apple II. Thanks to the expandability Woz had designed into the Apple II from the start, the machine was able to incorporate the new technology effortlessly. Even at $600, a very competitive price for a floppy-disk system at the time, Woz’s minimalist design aesthetic combined with the Apple II’s amenability to expansion meant that Apple made huge margins on the product; in West of Eden, Frank Rose claims that the Disk II system was ultimately as important to Apple’s early success as the Apple II itself. The PET and TRS-80 eventually got floppy-disk drives of their own, but only in a much uglier fashion; a TRS-80 owner who wished to upgrade to floppy disk, for instance, had to first buy Radio Shack’s bulky, ugly, and expensive “expansion interface,” an additional big box containing the slots that were built into the Apple II.

Another killer app enabled by the Apple II’s open architecture had a surprising source: Microsoft. In 1980, that company introduced its first hardware product, a Zilog Z80 CPU on a card which it dubbed the SoftCard. An Apple II so equipped had access to not only the growing library of Apple II software but also to CP/M and its hundreds of business-oriented applications. It gave Apple II owners the best of both worlds for just an additional $350. Small wonder that the card sold by the tens of thousands for the next several years, until the gradual drying up of CP/M software — a development, ironically, for which Microsoft was responsible with its new MS-DOS standard — made it irrelevant.

While most 6502-based computers were considered home and game machines of limited “serious” utility, products like the SoftCard and the various video cards that let it display 80 columns of text on the screen — an absolute requirement for useful word processing — lent the Apple II the reputation of a machine as useful for work as it was for play. This reputation, and the sales it undoubtedly engendered, were once again ultimately down to all those crazy slots. In this sense the Apple II much more closely resembled the commodity PC design first put together by IBM in 1981 than it did any subsequent design from Apple itself.

Another significant advantage that the Apple II had over its early competitors was its ability to display bitmap graphics. The TRS-80 and the PET, you may recall, were essentially limited to displaying text only. While it was possible to draw simple pictures using the suite of simple shape glyphs these machines provided in addition to traditional letters and punctuation (see my post on Temple of Apshai on the TRS-80), this technique was an inevitably limited one. The Apple II, however, provided a genuine grid of 280 X 192 individually addressable pixels. Making use of this capability was not easy on the programmer, and it came with a host of caveats and restrictions. Just 4 colors were available on the original Apple II, for instance, and oddities of the design meant that any individual pixel could not always be any individual desired color. These circumstances led to the odd phasing and color fringing that still makes an Apple II display immediately recognizable even today. Still, the Apple II was easily the graphical class of the microcomputer field in 1977. (I’ll talk a bit more about the Apple II’s graphical system and its restrictions when I look at some specific games in future posts.)

So, Woz was all over the Apple II, in these particulars as well as many others. But where was Jobs?

He was, first of all, performing the role he always had during his earlier projects with Woz, that of taskmaster and enabler. Left to his own devices, Woz could lose himself for weeks in the most minute and ultimately inconsequential aspects of a design, or could drift entirely off task when, say, some new idea for an electronically enabled practical joke struck him. Jobs therefore took it upon himself to constantly monitor Woz and the pair of junior engineers who worked with him, keeping them focused and on schedule. He also solved practical problems for them in that inimitable Steve Jobs way. When it became apparent that it was going to be very difficult to design the RF modulator needed for hooking the computer up to a television (dedicated monitors at the time were a rare and pricy luxury) without falling afoul of federal RF interference standards, he had Woz remove this part from the computer entirely, passing the specifications instead on to a company called M&R Electronics. When sold separately and by another company, the RF modulator did not need to meet the same stringent standards. Apple II owners would simply buy their RF modulators separately for a modest cost, and everyone (most of all M&R, who were soon selling the little gadgets by the thousands) could be happy.

Such practical problem-solving aside, Jobs’s unique vision was also all over the finished product. It was Jobs who insisted that Woz’s design be housed within a sleek, injection-molded plastic case that looked slightly futuristic, but not so much as to clash with the decor of a typical home. It was Jobs who gave the machine its professional appearance, with its screws all hidden away underneath and with the colorful Apple logo (a reference to the machine’s unique graphical capabilities) front and center.

Jobs, showing a prejudice against fan noise that has continued with him to the present day, insisted that Woz and company find some other way to cool it, which feat they managed via a system of cleverly placed vents. And it was Jobs who gave the machine its unique note of friendly accessibility, via a sliding top giving easy access to the expansion slots and, a bit further down the line, unusually complete and professional documentation in the form of big, glossy, colorful manuals. Indeed, much of the Apple II ownership experience was not so far removed from the Apple ownership experience of today. Jobs worked to make Apple II owners feel themselves part of an exclusive club, a bit more rarified and refined than the run-of-the-mill PET and TRS-80 owners, by sending them freebies and updates (such as the aforementioned new manuals) from time to time. And just like the Apple of today, he was uninterested in competing too aggressively on price. If an Apple II cost a bit more — actually, a lot more, easily twice the price of a PET or TRS-80 — it was extra money well spent. Besides, what adds an aura of exclusivity to a product more effectively than a higher price? What we are left with, then, is a more expensive machine, but also an unquestionably better machine than its competitors, and — a couple of years down the road at least, once its software library started to come up to snuff — one uniquely suited to perform well in many different roles for many different people, from the hardcore hacker to the businessman to the teacher to the teenage videogamer.

When the Apple II made its debut at the first West Coast Computer Faire in April of 1977, Jobs’s promotional instincts were again in evidence. In contrast to the other displays, which were often marked with signs hand-drawn in black marker, Apple’s had a back-lit plexiglass number illuminating the company’s new logo; it still looks pretty slick even today.

In light of the confusion that still exists over who deserves the credit for selling the first fully assembled PC, perhaps we should take a moment to look at the chronology of the trinity of 1977. Commodore made the first move, showing an extremely rough prototype of what would become the PET at the Winter Consumer Electronics Show in January of 1977. It then proceeded to show progressively less rough prototypes at the Hanover Messe in March (a significant moment in the history of European computing) and the West Coast Computer Faire. However, the design was not fully finalized until July, and the first units did not trickle into stores until September. Even then, PETs remained notoriously hard to come by until well into 1978, thanks to the internal chaos and inefficiency that seemed endemic to Commodore throughout the company’s history. (Ironically, Jobs and Woz had demonstrated the Apple II technology privately to Commodore as well as Atari in 1976, offering to sell it to them for “a few hundred thousand” and positions on staff. They were turned down; Commodore, immensely underestimating the difficulty of the task, decided it could just as easily create a comparable design of its own and begin producing it in just a few months.) The TRS-80, meanwhile, was not announced until August of 1977, but appeared in Radio Shack stores in numbers within weeks of the PET to become by several orders of magnitude the biggest early seller of the trinity. And the Apple II? Woz’s machine was in a much more finished state than the PET at the West Coast Computer Faire, and began shipping to retailers almost right on schedule in June of 1977. Thus, while Commodore gets the credit for being the first to announce a pre-built PC, Apple was the first to actually follow through and ship one as a finished product. Finally, Radio Shack can have the consolation prize of having the first PC to sell in large numbers — 100,000 in just the last few months of 1977 alone, about twice the quantity of all other kit or preassembled microcomputers sold over the course of that entire year.

Actually, that leads to an interesting point: if Apple’s status as the maker of the first PC is secure, it’s also true that the company’s rise was not so meteoric as popular histories of that period tend to suggest. As impressive as both the Apple II and Jobs’s refined presentation of it was, Apple struggled a bit to attract attention at the West Coast Computer Faire in the face of some 175 competing product showcases, many of them much larger if not more refined than Apple’s. Byte magazine, for instance, did not see fit to so much as mention Apple in its extensive writeup of the show. Even after the machine began to ship, early sales were not breathtaking. Apple sold just 650 Apple IIs in 1977, and struggled a bit for oxygen against Radio Shack with its huge distribution network of stores and immense production capacity. The next year was better (7600 sold), the next even better (35,000 sold, on the strength of increasingly robust software and hardware libraries). Still, the Apple II did not surpass the TRS-80 in total annual sales until 1983, on the way to its peak of 1,000,000 sold in 1984 (the year that is, ironically, immortalized as the Year of the Macintosh in the popular press).

Apple released an enhanced version of the II in 1979, the Apple II Plus. This model usually shipped with a full 48 K of RAM, a very impressive number for the time; the original Apple II had initially had only 4 K as standard equipment. Also notable was the replacement in ROM of the original Integer BASIC, written by Woz himself years ago when he first started attending Homebrew Computer Club meetings, with the so-called AppleSoft BASIC. AppleSoft corrected a pivotal flaw in the original Integer BASIC, its inability to deal with floating-point (i.e., decimal) numbers. This much more full-featured implementation was provided, like seemingly all microcomputer BASICs of the time, by Microsoft. (As evidenced by AppleSoft BASIC and products like the SoftCard, Microsoft often worked quite closely with Apple during this early period, in marked contrast to the strained relationship the two companies would develop in later years.) Woz also tweaked the display system on the II Plus to manage 6 colors in hi-res mode instead of just 4.

By 1980, then, the Apple II had in the form of the II Plus reached a sort of maturity, even though holes — most notably, a lack of support for lower-case letters without the purchase of additional hardware — remained. It was not the best-selling machine of 1980, and certainly far from the cheapest, but in some ways still the most desirable. Woz’s fast and reliable Disk II design coupled with the comparatively cavernous RAM of the II Plus and the machine’s bitmap graphics capabilities gave inspiration for a new breed of adventure games and CRPGs, larger and more ambitious than their predecessors. We’ll begin to look at those developments next time.

In the aftermath of even the Apple II’s first, relatively modest success, Jobs began working almost immediately to make sure Apple’s follow-up products reflected only his own vision of computing, gently easing Woz out of his central position. He began to treat Woz as something of a loose cannon to be carefully managed after Woz threatened Apple’s legendary 1980 IPO by selling or even giving away chunks of his private stock to various Apple employees who he just thought were doing a pretty good job and deserved a reward, gosh darn it. The Apple III, also introduced in 1980, was thus the product of a more traditional process of engineering by committee, with Woz given very little voice in the finished design. It was also Apple’s first failure, largely due to Jobs’s overweening arrogance and refusal to listen to what his engineers were telling him. Most notably, Jobs insisted that the Apple III, like the Apple II, ship without a cooling fan. This time, no amount of clever engineering hacks could prevent machines from melting by the thousands. Perhaps due to the deeply un-Jobs-ian hackerish side of its personality, Jobs tried repeatedly to kill the Apple II, with little success; it remained the company’s biggest seller and principal source of revenue when he resigned from Apple in a huff following an internal dispute in 1985.

In February of 1981, Woz crashed the small airplane he had recently learned how to fly, suffering serious head trauma. This event marked the end of his truly cutting-edge engineering years, at Apple or anywhere else. Perhaps he took the crash as a wake-up call to engage with all those other wonders of life he’d been neglecting during the years he’d spent immersed in circuits and code. It’s also true, though, that the sort of high-wire engineering Woz did throughout the 1970s (not only with Apple and privately, but also with Hewlett Packard) is very mentally intense, and possibly Woz’s brain had been changed enough by the experience to make it no longer possible. Regardless, he began to interest himself in other things: going back to university under an assumed name to finish his aborted degree, organizing two huge outdoor music and culture festivals (The “US Festivals” of 1982 and 1983), developing and trying to market a universal remote control. He is still officially an employee of Apple, but hasn’t worked a regular shift in the office since February of 1987. He wrote an autobiography (with the expected aid of a professional co-author) a few years ago, maintains a modest website, contributes to various worthy causes such as the Electronic Frontier Foundation, and, most bizarrely, made a recent appearance on Dancing with the Stars.

Asked back in 2000 if he considered himself an entrepreneur, Woz had this to say:

Not now. I’m not trying to do that because I wouldn’t put 20 hours a day into anything. And I wouldn’t go back to the engineering. The way I did it, every job was A+. I worked with such concentration and focus and I had hundreds of obscure engineering or programming things in my head. I was just real exceptional in that way. It was so intense you could not do that for very long—only when you’re young. I’m on the board of a couple of companies that you could say are start-ups, so I certainly support it, but I don’t live it. The older I get the more I like to take it easy.

Woz has certainly earned the right to “take it easy,” but there’s something that strikes me a little sad about his post-Apple II career, as the story of a man who never quite figured out what to do for a second act in life. And the odd note of subservience that always marked his relationship with Jobs is still present. From the same interview:

You know what, Steve Jobs is real nice to me. He lets me be an employee and that’s one of the biggest honors of my life. Some people wouldn’t be that way. He has a reputation for being nasty, but I think it’s only when he has to run a business. It’s never once come out around me. He never attacks me like you hear about him attacking other people. Even if I do have some flaky thinking.

It’s as if Woz, God bless his innocence, still does not understand that he was really treated rather shabbily by Jobs, and that, in a very real sense, it was he that made Jobs. In that light, it seems little enough to expect that Jobs refrain from hectoring him as he would one of his more typical employees.

As for Jobs himself… well, you know all about what became of him, right?

 
14 Comments

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

 

Tags: