RSS

Tag Archives: muse

Robot War, Anyone?

So, I’ve been getting some positive rumbles in support of a Robot War tournament. Let me therefore offer a proposal as to how it might work.

The tournament will progress through a series of single-elimination rounds, with each match being a one-on-one contest, opponents randomly determined. Should there be an odd number of robots in a round, the one left unchosen will get a bye into the next round. That might seem quite a nice bit of luck, but it’s mixed blessing in that the creator of that robot will not get an opportunity to see it in action prior to making adjustments for the next round (see the next paragraph).

I’ll run each match just one time, record it, and post it to the blog as a movie. Each round will be separated by a week or so, during which each contestant whose robot remains alive in the tournament can tinker or even, if he likes, entirely rewrite his robot. In this he can be guided not only by his own robot’s performance in the previous round, but also by that of his next opponent’s; I’ll announce matchups for the next round immediately after the previous is complete. (Of course, said opponent may also be changing her robot as well, making this very much a cat-and-mouse — or, if you like, bait-and-switch — game.)

You can modify or steal code from any of the five sample robots that come with the game, but I’ll have to take you on your word of honor that you won’t use or even examine the code to any of the robots published in places like Computer Gaming World back in the day, or available online somewhere. You are welcome to submit a robot you created by yourself at some earlier date. Although, again, I can’t really stop you, teams will not be allowed, as having two or more minds working on a problem gives an unfair advantage. One man one robot is the rule.

And that’s about it really. We continue like this until we determine a champion. I’m trying like mad to think of something to offer as a prize to the winner. I have this book coming out that I wrote about the Amiga, but I’m afraid that offering that to a bunch of Apple II fans might be like setting up a hot-dog stand outside a vegetarians convention. If you don’t want that and you do have a Kindle Keyboard or Touch, there is this game I wrote

The final decision on whether to do this hinges on whether enough people want to participate to make it worthwhile; there’s nothing more depressing than winning a “contest” with two or three participants (not to mention hosting one). I figure we need at least ten to have a contest that feels like a proper tournament. If you’re willing to commit to participate, please leave a comment here or, if you’re not a fan of comments, send me an email. If you’re interested but not happy with the rules I’ve just outlined, let me know that as well. If we can come to a consensus, we can always adjust.

I know that some of you who read this blog are involved with the Apple II community and/or other groups that might be interested in this kind of thing. If you know anyone whom you think might want to participate, please direct them this way. Likewise, if you have blogs, Twitter feeds, podcasts, etc., frequented by the right kind of folks, a quick plug would be hugely appreciated.

And if you’re not an Apple II old-timer and want to know if this is for you…

You don’t need any Apple II-specific knowledge at all, only the willingness to install an emulator and boot it from the Robot War disk image. (Solid emulators are available for Windows, Mac, and Linux, and probably other platforms as well.) On the other hand, this is a programming game, so you will need to learn a simple programming language to participate. On the other other hand, it’s a very, very simple language. Probably the most awkward part of the whole process will be typing and editing your source with Robot War‘s built-in editor that replaces mice and menus with control-key combinations. If you live in the Unix/Linux world and/or are comfortable with terminal-based text editors like vi, it won’t be a big stretch; otherwise it might give you 20 minutes frustration before it starts to click.

So, let me know if you’re in, and tell you’re friends, and we’ll see if we’ve got the numbers to make it happen.

(Update: We gave it a good try. Thanks to Ken Gagne and others in the Apple II community for working to get the word out. Even with all their efforts, though, we don’t quite have the number of firm commitments to make proceeding viable in my view. So the would-be Great Robot War Tournament of 2012 will not be happening, I’m afraid. Ah, well… I have enough to do as it is.)

 
 

Tags: , ,

Robot War

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

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

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

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

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

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

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

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

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

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

;SAMPLE ROBOT 'RANDOM'

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

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

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

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

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

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

 
 

Tags: , ,

Silas Warner and Muse Software

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
 

Tags: , ,

Escape!

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

 
6 Comments

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

 

Tags: , , ,

Lord British

If you wanted to breed a game designer, you could do worse than starting with an engineer father and an artist mother. At any rate, that’s the combination that led to Richard Garriott.

Father Owen had quite a remarkable career in his own right. In 1964 he was at age 33 a professor of electrical engineering at Stanford University when NASA, in the thick of the moon race, put out the call for its fourth group of astronauts. This group of six would be different from all that came before, for, in spite of much grumbling from within and without the organization (not least from the current astronauts themselves), they would be selected from the ranks of civilian scientists and engineers rather than military pilots. Owen applied in the face of long odds: no fewer than 1350 others had the same idea in moon-mad America. He survived round after round of medical and psychological tests and interviews, however, until in May of 1965 none other than the first American to fly into space, Alan Shepard, called him in the middle of a lecture to tell him he was now an astronaut. Owen and family — including a young Richard, born in 1961 — moved to the Houston area, to a suburb called Clear Lake made up almost entirely of people associated with the nearby Manned Spacecraft Center. While Owen trained (first task: learning how to fly a jet), the rest of the family lived the exciting if rather culturally antiseptic lives typical of NASA, surrounded by science and gadgetry and all the fruits of the military-industrial complex. Whether because NASA did not quite trust these scientist-astronauts or because of the simple luck of the draw, only one from Owen’s group of six actually got the chance to go to the moon, and it wasn’t Owen. As a consolation prize, however, Owen flew into space on July 28, 1973, as part of the second crew to visit Skylab, America’s first semi-permanent space station, where he spent nearly two months. After that flight Owen stayed on with NASA, and would eventually fly into space again aboard the space shuttle in November of 1983. And those are just the adventurous highlights of a scientific and engineering career filled with awards, publications, and achievements.

Such a father certainly provided quite an example of achievement for a son, one that Richard took to heart: beginning with his kindergarten year, he entered a project into his school’s science fair every single year until he graduated high school, each one more ambitious than the last. But such an example could also, of course, be as intimidating as it was inspiring. It didn’t help that Owen was by nature an extremely reserved man, sparing of warmth or praise or obvious emotion of any stripe. Richard has spoken of his disappointment at his father’s inability to articulate even the most magical of his experiences: “My dad never told me anything about being in space. He once said it was kind of like scuba diving, but he never said anything with any kind of emotion.” Nor did Owen’s career leave him much time for Richard or his siblings, two older brothers and a younger sister.

The job of parenting therefore fell mostly to Helen Garriott. An earthier, quirkier personality than her husband, Helen’s passion — which she pursued with equal zeal if to unequal recognition as her husband’s scientific career — was art: pottery, silversmithing, painting, even dabblings in conceptual art. While Owen provided occasional words of encouragement, Helen actively helped Richard with his science-fair projects as well as the many other crazy ideas he and his siblings came up with, such as the time that he and brother Robert built a functioning centrifuge (the “Nauseator”) in the family’s garage. With the example of Owen and the more tangible love and support of Helen, all of the children were downright manic overachievers virtually from the moment they could walk, throwing themselves with abandon into projects both obviously worthwhile (the science fairs) and apparently frivolous (the Nauseator, in which the neighborhood children challenged each other to ride until they vomited).

For Richard’s freshman year of high school, 1975-76, Owen temporarily returned the family to Palo Alto, California, home of Stanford, where he had accepted a one-year fellowship. Situated in the heart of Silicon Valley as it was, Richard’s high school there was very tech-savvy. It was here that he was first exposed to computers, via the terminals that the school had placed in every single classroom. He was not particularly excited by them, however; indeed, it was his parents that first got the computer religion. Upon returning to Houston for his sophomore year, Richard dutifully enrolled in his high school’s single one-semester computer course at their behest, in which an entire classroom got to program in BASIC via the school’s single clunky teletype terminal, connected remotely to a CDC Cyber mainframe at some district office or other. Richard aced the class, but was, again, nonplussed. So his parents tried yet again, pushing him to attend a seven-week computer camp held that summer at Oklahoma University. And this time it took.

Those seven weeks were an idyllic time for Richard, during which it all seemed to come together for him in a sort of nerd version of a summer romance. On the very first day at camp, his fellow students dubbed him “Lord British” after he greeted them with a formal “Hello” rather than a simple “Hi.” (The nickname was doubly appropriate in that he was actually born in Britain, during a brief stint of Owen’s at Cambridge University.) The same students also introduced him to Dungeons and Dragons. With the pen-and-paper RPG experience fresh in his mind as well as The Lord of the Rings, which he had just read during the previous school year, Richard finally saw a reason to be inspired by the computers that were the ostensible purpose of the camp; he began to wonder if it might not be possible to build a virtual fantasy world of his own inside their memories. And he also found a summer girlfriend at camp, which never hurts. He came back from Oklahoma a changed kid.

In addition to his experiences at the computer camp, the direction his life would now take was perhaps also prompted by a conversation he had had a few years before, during a routine medical examination conducted (naturally) by a NASA doctor, who informed that his eyesight was getting worse and that he would need to get glasses for the first time. That’s not the end of the world, of course — but then the doctor dropped this bomb: “Hey, Richard, I hate to be the one to break it to you, but you’re no longer eligible to become a NASA astronaut.” Richard claims that he had not been harboring the conscious dream of following in his father’s footsteps, but the news that he could not join his father’s private club nevertheless hit him like a personal rejection. Even in late 1983, as he was amassing fame and money as a game developer beyond anything his father ever earned, he stated to an interviewer that he would “drop everything for the chance to go into space.” Much later he would famously fulfill that dream, but for now his path must be in a different direction. The computer camp gave him that direction: to become a creator of virtual worlds.

Back in suburban Houston, Richard began a D&D recruiting drive, starting with the neighbor kids with whom he’d grown up and working outward from there. By a couple of months into his junior year, Richard with the aid of his ever-supportive mother was hosting weekend-long sessions in the family home. By early 1978, multiple games were going on in different parts of the house, and even some adults had started to turn up, to game or just to smoke and drink and socialize on the front porch.

To understand how this could happen, you have to understand something about Richard. Although his interests — science, D&D, computers, Lord of the Rings — were almost prototypically nerdy, in personality and appearance he was not really your typical introverted high-school geek. He was a trim, good-looking kid with a natural grace that kept the schoolyard bullies at bay. Indeed, he co-opted them; those weekend sessions were remarkable for bringing together all of the usually socially segregated high-school cliques. Most of all, Richard was very glib and articulate for his age, able when he so chose to cajole and charm almost anyone into anything in a way that reminds of none other than that legendary schmoozer Steve Jobs himself. His later friend and colleague Warren Spector once said that Richard “could change reality through the force of will [and] personal charisma,” echoing the legends of Jobs’s own “reality distortion field.” He turned those qualities to good use in finding a way to achieve the ultimate dream of all nerds at this time: regular, everyday access to a computer.

With only one computer class on the curriculum, the school’s single terminal sat unused the vast majority of the time. On the very first day of his junior year, Richard marched into the principal’s office with a proposal. From Dungeons and Dreamers:

He’d conceive, develop, and program fantasy computer games using the school’s computer [terminal], presenting the principal and the math teacher with a game at the end of each semester. There wasn’t even a computer teacher there to grade him on his skills. To pass the class, he simply had to turn in a game that worked. If he did, he’d get an A. If it didn’t, he’d fail.

Incredibly — and here’s where the reality distortion field really comes into play — the principal agreed. Richard claims that the school decided to count BASIC as his foreign-language credit. (A decision which maybe says a lot about the state of American language training — but I digress…)

Accordingly, when not busy with schoolwork, the science fair (which junior and senior projects also used the computer extensively), tabletop D&D, or the Boy Scouts Explorers computer post he joined and (typically enough) soon became president of, Richard spent his time and energy over the next two years on a series of computer adaptations of D&D. The development environment his school hosted on its aging computer setup was not an easy one; his terminal did not even have a screen, just a teletype. He programmed by first writing out the BASIC code laboriously by hand, reading it through again and again to check for errors. He then typed the code on a tape punch, a mechanical device that resembled a typewriter but that transcribed entered characters onto punched tape (a ribbon of tape onto which holes were punched in patterns to represent each possible character). Finally he could feed this tape into the computer proper via a punched-card reader, and hope for the best. A coding error or typo meant that he got to type the whole thing out again. Likewise, he could only add features and improvements by rewriting and then retyping the previous program from scratch. He took to filling numbered notebooks with code and design notes, one for each iteration of the game, which he called simply D&D. By the end of his senior year he had made it all the way to D&D 28, although some iterations were abandoned as impractical for one reason or another before reaching fruition as an entered, playable game.

In building his games, Richard was largely operating in a vacuum, trying things out for himself to see what worked. He had been exposed to the original Adventure when his Boy Scouts Explorers visited the computer facilities at Lockheed, but, uniquely amongst figures I’ve discussed in this blog, was nonplussed by it: “It was very different from the kind of thing I wanted to write, which was something very freegoing, with lots of options available to you, as opposed to a ‘node’ game like Adventure. At that time, I didn’t know of any other games that would let you go anywhere and do anything.” From the very beginning, then, Richard came down firmly on the side of simulation and emergent narrative, and, indeed, would never take any interest in the budding text-adventure phenomenon. It’s possible that the early proto-CRPGs hosted on the PLATO network would have been more to his taste, but it doesn’t appear that Richard was ever exposed to them. And so his D&D games expressed virtually exclusively his own vision, which he literally built up from scratch, iteration by iteration.

But how did they play? Because they were stored only on spools of tape, we don’t have them to run via emulation. (On the other hand, Richard has donated a paper tape containing one of the games to the University of Texas as part of the Richard Garriott Papers collection. If someone there could either get an old tape reader working to read it in or — if truly dedicated — translate the punches by hand, the results would be fascinating to see.) We do have, however, a pretty good idea of how they operated: more primitive than, but remarkably similar to, the commercial games that would soon make Richard famous. In fact, Richard has often joked that he spent his first fifteen or so years as a designer essentially making the same game over and over. The D&D games, like the Ultimas, show a top-down view of the player’s avatar and surroundings. They run not in real-time but in turns. The player interacts with the game via a set of commands which are each triggered by a single keypress: “N” to go north, “S” to view her character’s vital statistics, “A” to attack, space to do nothing that turn, etc. Because the games were running on a teletype, scenery and monsters could be represented only by ASCII characters; a “G” might represent a goblin, etc. And unlike the later games, the top-down view was maintained even in dungeons. This description reminds one strongly of the roguelikes of today, and of course of their ancestors on the PLATO system. It’s interesting that Richard came up with something so similar working independently. (Although on the other hand, how else was he likely to do it?) Playing the games would have required almost as much patience as writing them, as well as a willingness to burn through reams of paper, for the only option Richard had was to completely redraw the “screen” anew on paper each time the player made a move.

As his time in high school drew toward a close in the spring of 1979, Richard found himself facing a crisis of sorts: not only would he not be able to work on D&D anymore, but he faced losing his privileged access to a computer in general. He was naturally all too aware of the first generation of PCs that had now been on the market for almost two years, but so far his father had been resistant to the idea of buying one for the family, not seeing much future in the little toys as opposed to the hulking systems he was familiar with at NASA. In desperation, Richard turned on the reality distortion field and marched into Owen’s den with a proposal: if he could get the latest, most complicated iteration of D&D working and playable, without any bugs, Owen should buy him the Apple II system he’d been lusting over. Owen was perhaps more resistant to the field than most, being Richard’s father and all, but he did agree to go halfsies if Richard succeeded. Richard of course did just that (as Owen fully expected), and by the end of the summer his summer job earnings along with Owen’s contribution provided for him at last Apple’s just released II Plus model.

Compared to what he had been working with earlier, the Apple II, with its color display and graphics capabilities, its real-time responsiveness, and its ability to actually edit and tinker with a program in memory, must have seemed like a dream. Even the cassette drive he was initially stuck using for storage was an improvement over manually punching holes in paper tape. Richard had just begun exploring the capabilities of his new machine when it was time to head off to Austin, where he had enrolled in the Electrical Engineering program (the closest thing the university yet offered to Computer Science) at the University of Texas.

Richard’s early months at UT were, typically enough for a university freshman, somewhat difficult and unsettling. He had left safe suburban Clear Lake, where he had known everyone and been regarded as a quirky neighborhood star (a sort of Ferris Bueller without the angst), for the big, culturally diverse city of Austin and UT, where he was just one of tens of thousands of students filling huge lecture halls. When not returning home to Houston, something he did frequently, he uncharacteristically spent most of his time holed up alone in his dorm, tinkering on the Apple. It was not until his second semester that he stumbled upon a flyer for something called the “Society for Creative Anachronism,” a group we’ve encountered before in this blog who had a particularly large and active presence in eclectic Austin. He threw himself into SCA with characteristic passion. Soon Richard, who had dabbled in fencing before, was participating in medieval duels, camping outdoors, making and wearing his own armor, arguing chivalry and philosophy in taverns, and learning to shoot a crossbow. Deeming the “Lord British” monicker a bit audacious for a newcomer, he took the name “Shamino” (inspired by the Shimano-brand gears in his bicycle) inside the SCA, playing a rustic woodman-type to which the closest D&D analogue was probably the ranger class. The social world of the Austin SCA would play a huge role in Richard’s future games, with most of his closest friends there receiving a doppelganger inside the computer.

Meanwhile he continued to explore the Apple II. A simplistic but popular genre of games at this time were the maze games, in which the computer generates a maze and expects the player to find her way out of it — think Hunt the Wumpus, only graphical and without all the hazards to avoid. Most examples used the standard top-down view typical of the era, but Richard stumbled over one written by Silas Warner of Muse Software and called simply Escape! which dropped its player into a three-dimensional rendering of a maze, putting her right inside it. “As the maze dropped down into that low perspective, I immediately realized that with one equation, you could create a single-exit maze randomly. My world changed at that moment.”

If you’d like to have a look at this game which so inspired Richard, you can download a copy on an Apple II disk image. After booting the disk on your emulator or real Apple II, type “RUN ESCAPE” at the prompt to begin.

Escape! inspired Richard to try to build the same effect into the dungeon areas of his D&D game, which he was now at work porting to the Apple II. Uncertain how to go about implementing it, he turned to his parents, who helped in ways typical of each. First, his mother explained to him how an artist uses perspective to create the illusion of depth; then, his father helped him devise a set of usable geometry and trigonometry equations he could use to translate his mother’s artistic intuition into computer code. Richard took to calling the Apple II version of his game D&D 28B, since it was essentially a port of the final teletype version to the Apple II, albeit with the addition of the 3D dungeons.

Richard spent the summer of 1980 back in Houston with his family, working at the local ComputerLand store to earn some money. His boss there, John Mayer, noticed the game he was tinkering with, which by this time was getting popular amongst Richard’s friends and colleagues at the store. Mayer did Richard the favor of a lifetime when he suggested that he might want to consider packaging the game up and selling it right there in the shop. Richard therefore put together some packaging typical of the era, sticking a mimeographed printout of the in-game help text and some artwork sketched by his mother into a Ziploc bag along with the game disk itself. (He had by this time been able to purchase a disk drive for his Apple II.) He retitled the game Akalabeth, after one of his tabletop D&D worlds. Deeply skeptical about the whole enterprise, he made somewhere between 15 and 200 copies (sources differ wildly on the exact number), and spent the rest of the summer watching them slowly disappear from the ComputerLand software wall. In this halting fashion a storied career was born.

We’ll look at Akalabeth in some detail next time.

 
15 Comments

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

 

Tags: , , ,