Tag Archives: robot war

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

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

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

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

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

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

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

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

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

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

;SAMPLE ROBOT 'RANDOM'

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

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

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

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

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

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

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.