RSS

Monthly Archives: January 2012

Robot War

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

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

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

The other way that Super-Text helped beget Robot War is more surprising, and gives me the opportunity to make one of 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 mirror 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: , ,

The King of Shreds and Patches, Kindle Touch Version — and Some Answers

I’m excited to announce that The King of Shreds and Patches is now available for purchase at Amazon in a version for the Kindle Touch as well as the Kindle Keyboard. Adapting the app to work on the small screen with the onscreen keyboard was a challenge, but we’ve arrived at last at something that both I and Amazon agree works really smoothly. If you have a Touch, I hope you’ll consider giving it a try. As always, your reviews and feedback are hugely appreciated — as are tweets, blog entries, etc., to help get the word out.

An Android version is also in the works. As shown by the picture, the game does run and is playable on the Kindle Fire and other Android tablets and phones. However, I still have quite a bit of work ahead of me to make it into a polished, bulletproof app. I hate to give myself deadlines, but with a bit of luck it may be available in the Amazon app store as well as the Barnes and Noble Nook store and of course the general Android store within a few months. Maybe.

I still get lots of questions about my future plans — which do actually involve more than releasing the same game on platform after platform. This seems as good a time and place as any to give some public answers. In fact, said answers are probably long overdue. So, if you’ll forgive my having a conversation with a straw man, let me first give some answers to some common queries.

How well is King doing on the Kindle?

Thanks largely to you guys who tweeted and blogged and got the word out, we had a pretty strong launch. Since then sales have inevitably tapered off, but the game still sells a little bit pretty much every day, and brings in a little extra money each month. All in all, I judge it a modest success. Hopefully as it appears on new platforms and as other games appear to join it (see below), we can really start to build something.

I understand that you have created an engine that can run Glulx games on the Kindle. When will you release that engine and (preferably) source to the public?

Not any time soon, I’m afraid. First of all, it wouldn’t do most of you all that much good. The only way to use this engine is by registering with Amazon as an official Kindle app developer, something that is not automatic, that takes some time even if you are eventually approved, and that as I understand it now involves a registration fee (I registered very early as a “beta” developer, at which time the fee was being waived). You will then be allowed to register a limited number of Kindles as development devices, which will be capable of running code signed by you only. In other words, there is no way for you to take my code and simply copy it onto a Kindle and run it. The Kindle app universe is, for better or for worse, very much a walled garden.

Secondly, I’ve spent a lot of time and labor developing these engines, and to justify that I really need to see something come back. If anyone wants to jump into what I’m going to optimistically label an emerging market, you’re welcome to do so. I just can’t justify handing you all my hard work. I’ve given and continue to give a lot to interactive fiction and its community; I hope I’ve earned the right to get a little bit back here. Please understand that this does not mean I want to horde the Kindle market for myself and my one game. See below for my grand vision of the future, which I like to think could benefit everyone who cares about IF.

When will you release a (commercial or free) standalone interpreter for IF on the Kindle?

Again, this isn’t going to happen. While it’s true that I do have a working Kindle Glulx interpreter, that wasn’t really the hard part of this project; the Glulx VM is pretty simple really, and by now I’ve worked with it enough that creating one for Java was pretty quick and straightforward. The challenge has been adapting IF to the very different interface paradigm of an e-reader. That requires considerable modifications to the story file, to add new GLK function calls that do things like define page and chapter breaks, to support a radically different approach to saving and undoing, and to tweak performance in places where Inform 7 is still inefficient. Creating the overall look and feel of The King of Shreds and Patches on the Kindle, which I’m gratified to say just about everyone has praised, required much, much more than just dropping a story file into an interpreter.

The next problem is that any theoretical interpreter would need to be approved by Amazon. They curate the Kindle app store very closely, looking not just for outright malware or broken programs but also deciding individually for each app whether it’s a good “fit” for the Kindle. They aren’t interested in an app that lets you run other games — that’s getting quite far afield from the Kindle philosophy of being an easy-to-use, simple device for everyday people, in addition to scaring the hell out of their legal department. (We all may know that story files cannot break out of their interpreters to do harm to the machines on which they run, but they don’t.)

To be frank, I’m not that interested in the idea either. One problem contemporary IF has is the old wheat-from-the-chaff dilemma. I would like to make the Kindle a place where only really first-class stories appear, stories that are polished and professional and worth spending a little bit of money on. Anyway, those who are technical enough to want a generic Kindle IF interpreter are probably also technical enough to jailbreak their Kindles and install one for themselves. If you want something that looks more polished than that… well, there’s really no way to give you that and also give it to you as a standalone interpreter.

What about the new base Kindle model?

All indications are that this thing is selling like crazy, but there’s just no way to make a parser-driven game tolerable on it. The only way to enter text is by laboriously selecting each letter from a menu using the five-way controller. I can’t imagine anyone wanting to play that way for hundreds or thousands of turns.

What about Europe?

I feel your pain, Mr. European Straw Man. I really do — especially because all the queries I’ve gotten must add up to quite a few sales I’m not making. Unfortunately, it’s entirely up to Amazon when and if they open up their non-U.S. Kindle stores to apps. Once the Android version is out, Europeans and others will at least be able to purchase the game in that version.

Will you release versions for the iOS devices?

The thing is, I’m just not an Apple guy. I don’t own the Macintosh system one needs to develop for those devices, nor do I own the devices themselves, nor am I excited about having to learn a new programming language and start over from scratch to develop for them. I’ve developed a good relationship with Amazon, and — even as I recognize what a huge market the Apple devices are — will be looking to build on the Kindle and Android platforms only for the foreseeable future. If someone experienced with iOS development were to express interest in developing a version of my engine for those devices, I’d certainly be ready to listen. Left to my own devices (pun intended), however, I don’t foresee taking on yet more huge programming challenges and big additional hardware expenses.

So, having told you what I’m not going to do, let me tell you a little bit of what my plans are in the short, medium, and long term.

In the short term, my immediate goal is obviously to get the Android version of The King of Shreds and Patches finished and into (at a minimum) Amazon, Barnes and Noble, and the Google Android store.

In the medium term, I want to publish other games from other authors on these platforms using these engines. I spent much of the latter part of last year developing extensions and tools to make that as painless as possible. It’s not quite a matter of “drop this extension into your Inform 7 source and you’re done,” and it never will be, but I’ve gone a long way toward building a very systemitized approach. Once I have solid engines on all three platforms (already have two out of three, of course), I’ll begin reaching out to some other authors whose games I think can work on these platforms and with these audiences. It’s not inconceivable that, authors willing, we could release half a dozen more games before the end of the year. (He says, knowing he’s likely to regret it round about December 31, 2012.)

Here’s a very optimistic vision of what could happen. The great IF community and the competitions could continue to run as they always have, with the additional incentive that those who author really great, really polished games will have the opportunity to get them published on the Kindle and Android devices. This would win them a whole lot more exposure, and would of course also give them the opportunity to earn some money back. I’m not sure anyone will be able to quit her day job, but you might just earn enough to take the spouse / significant other / family on a nice little vacation to pay them back for putting up with all those long evenings you spent alone in front of the computer rather than with them. Maybe such an incentive could lead to more games and better games, things the community could dearly use. In this vision the current IF community loses nothing. The hardcore will still have games to play, for free if they like, and all of the support and technical know-how will be as freely shared as ever. It’s just that now the community serves as a feeder system for a (hopefully) bigger market of more casual players who are just interested in playing a fun/interesting game/story now and then rather than discussing craft, beta testing (willingly or unwillingly), or trying to get through 40 or more games in six weeks for this competition thing — much less actually trying to write games themselves. Authors would retain the rights to their games on other platforms, meaning that if someone else wanted to publish them on (for instance) those Apple platforms I’m neglecting, they could feel free.

If you are interested in writing a game that can work in these markets, I’ll give you some guidelines. All of my tools are currently oriented toward Inform 7, so it’s definitely best to work in that language rather than Inform 6. (And TADS, much as I hate to say it about a very worthy system, is currently a complete nonstarter.) You also should plan to target Glulx rather than the Z-Machine. Your options for multimedia are, shall we say, very limited. You can display an occasional picture in-line with the text; in fact, that’s desirable. Not too many, though, because pictures add to the download size, using bandwidth Amazon will make us pay for out of the sales proceeds. Sound is a nonstarter for now, as are additional windows or really anything beyond the very traditional status line / text window approach that’s been with us since Zork. The screens we’re working with are just too small to get fancy here.

As far as design goes, puzzles are acceptable and, indeed, desirable, but they need to be fair puzzles. You will also need a hint system, preferably something context-sensitive like that in King. You can include a map with the app, but don’t use that as a license to create an overly convoluted geography. The game obviously needs to be very polished and well-written, and it needs to foreground a strong, interesting story with some forward drive. Genre works are great and in fact preferred, but nothing too geek-centric or esoteric. This is also probably not the market for formal experimentation or for getting too “literary,” at least right now. If interactive fiction can start to build an identity on these devices, this may change, but for right now the reality is that we’re competing against the likes of Final Fantasy gamebook adaptations. Hopefully we can do a bit better than them in the writing sweepstakes, but still, I’m looking more for solid genre novels than deep works of unfathomable beauty — Stephen King and Robert Heinlein rather than James Joyce and Umberto Eco.

In the long term, I think that the new generation of touchscreen devices offer some really interesting opportunities to get away from the parser at last without having to settle for Choose-Your-Own-Adventure-style menus. I even think that (again, in the long term) this is the real path forward for IF. I’m excited by all of the experiments that have been taking place lately with alternative interface paradigms, and have some ideas of my own brewing. I’d love to bring some of these ideas together and build or help to build a next-generation IF system designed with touchscreens in mind (but still very usable with conventional GUIs). But that is of course another big, daunting technical challenge.

And, truly looking through the fat end of the telescope, I want to write another game, hopefully using that next-generation interface. Doing that, however, is kind of dependent on everything above happening first. Too bad, because I’m itching to start…

 
 

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 play 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 accountent 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.

 
4 Comments

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

 

Tags: , ,

Escape!

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

 
6 Comments

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

 

Tags: , , ,

Exploring Zork, Part 3

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

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

Within the maze is the “CYCLOPS ROOM.”

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

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

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

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

>EXAMINE BOOK
COMMANDMENT #12592

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

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

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

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

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

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

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

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

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

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

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

 
 

Tags: , ,