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
] DAMAGE TO D ;SAVE CURRENT DAMAGE
] IF DAMAGE # D GOTO MOVE ;TEST — MOVE IF HURT
] AIM+17 TO AIM ;CHANGE AIM IF OK
] 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
] RANDOM TO H
] RANDOM TO V ;PICK RANDOM PLACE TO GO
] 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
] 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.
January 30, 2012 at 6:08 pm
Of interest: (nostalgia for) Robot War is one of the primary reasons why we have CFFA and CFFA3000 cards now – Rich Dreher mentions he wanted a way to continue to play this game as a catalyst for his hardware exploits.
January 30, 2012 at 8:36 pm
Heh. I remember playing TclRobots and being very proud when my very simple robot nevertheless got to the point where it could take on any of those shipped with the software in a free for all, and for some models even when three of them teamed up (there could be at most 4 robots in the arena at once). Too bad the software wasn’t very portable; as Tcl evolved, it stopped running entirely, and I never got around to fixing it. Other similar games were too complicated for my taste, so I drifted away from programming games much too soon. But I remember them fondly, and it’s nice to know the genre was born on microcomputers.
January 31, 2012 at 4:55 am
This blog is starting to move through my childhood!
I guess I was aged around 7-8 when my dad bought us Robot War. The first thing he had taught me on our Apple II+ was BASIC. The 2nd programming language I encountered in life was Robot War’s. Unsurprisingly it was too tough for me to program very well at that age, and even later I tried to make a more sophisticated robot and it didn’t work too brilliantly. But certainly it was fascinating setting the robots loose and just watching them fight without your direct intervention. That was a total novelty. I still have the original Robot War package and manual.
October 21, 2013 at 4:07 am
Right on, Wade. Same here!! Good times, right?
January 31, 2012 at 8:59 am
Born on the PLATO system, actually, like the CRPG. ;)
January 31, 2012 at 5:51 am
I was particularly enamoured of Origin’s Omega, which was very much an updated take on this game.
January 31, 2012 at 4:56 pm
Reminds me of the board game Robo Rally.
January 31, 2012 at 10:16 pm
Robot War continues to be one of my all-time core favorite games, due to both being a programming gateway and a continued fascination I have with the idea of the Robot War Tournaments, and the ability to objectively match wits remotely, a potential to be massively multi-player, yet not online. I occasionally look for a Robot depository, besides the known publish Robots one can find online. And sometimes, I wish that there would be another tourney. . .
March 3, 2014 at 1:31 am
I worked with silas and ed zaron and one day as i was working…a robot based on an apple II came motoring into my office!
Silas and ed had the idea of creating Real robots that could run the programs written for the virtual arena…and make real silicon and metal robots fight it out.
Sadly that idea never came to fruition. But in this day of DIY robots…i keep thinking that this could rwally happen!
February 10, 2012 at 10:44 am
I’m going through stuff (and throwing stuff *away*, shock, horror — but only replaceable stuff, of course) and found a printout of the User Manual for Arena 2.1, (c) 1985 Richard Brown.
Looks like a PC take on Robotwar.
If I remember this came on a set of shareware floppies which I undoubtedly still have somewhere.
Google doesn’t tell me much.
April 18, 2012 at 10:54 pm
Hi wrm, interesting comment about Arena 2.1. Do you have any further details? I’m compiling a history of programming games and haven’t come across this one yet…
April 18, 2012 at 10:56 pm
Hi Jimmy, do you have a reference for the Softtalk articles? Thanks :-)
April 19, 2012 at 7:08 am
It’s in the January, 1981, issue of Softalk.
May 5, 2012 at 2:34 pm
Thanks, I managed to find a scan online :-)
September 12, 2013 at 11:12 am
Further to Arena mentioned above I also added a blogpost about Warbots which I found on an old floppy. While Robot War looks like Basic, Arena looks like x86 assembler and Warbots looks like Pascal.
December 15, 2015 at 12:38 pm
Hi, I have a -?- Scourge Earth, the one with the tanks shooting each other, was it influenced by or result of Robot Wars? Sounds like they are the “same yet opposites” if you catch my drift. Both you have to put in “input” though Scourge its Angle and Power. Played that one till who knows when and find it works on winXP and even win7 without problems! (And the clones of that one! The one with gorillas throwing Bananas, just one coming to mind!)
As for that lines and stuff in the start of the article, when I worked at FNB (banking) security, the managers thought it would be excellent to do the Occurrence Book. I knew of these wisi-thingies (due to my wife of course) and quickly made my entries with those double lines, using alt key and number! I went so fan as to have the time, date, entry and all the other stuff neatly in boxes!
Going to try that robot war as it is one of the old “old school” games that me and the wife enjoy together!
January 24, 2017 at 1:49 pm
I actually knew Silas Warner of M.U.S.E.. Silas was very tall about 6’8″ with a very large beer gut. I am a computer journalist. I started writing reviews of games in the 1970s. I have thousands of published reviews. I published in Johnny’s Computer Gaming World. Katz, Kunkel and Worleys Computer Games and Video Entertainment, Electronic Entertainment, Compute, etc. I went to CES, Comdex, E3, Pax, etc. I would visit many of the computer gaming companys, including Westwood, Dynamix, Microprose, Origin, Sierra, Blizzard, Electronic Arts, Brian Fargo’s Interplay Productions, Robert Sirotech’s Sir-Tech Software, etc.
October 26, 2017 at 10:00 am
“a document on the screen can be rendered as a mirror image of what will appear when you click “Print.””
I found that a very odd metaphor: I immediately found myself trying to envisage a screen in which left and right were reversed.
October 27, 2017 at 8:37 am
March 27, 2019 at 11:20 am
One of the only games that I purchased, all others were just copies handed out by Apple ][ fans…
I spent hours and hours programming my robot, I don’t remember if I called it bottom or corner, but it would immediately go to the bottom and keep moving while shooting.
I liked the editor so much, that I made a copy. I found that the catalog (disk directory) was in a different track, so I made a different disk with only the editor. I remember this took me weeks of sleepless nights! But totally worth it.
January 9, 2020 at 1:35 am
“and in having a single rotable radar dish it can use to “see” and a single rotatable gun it can use to shoot.”
January 9, 2020 at 5:48 am
April 25, 2020 at 9:59 pm
make one of little lessons -> make one of my(?) little lessons
April 26, 2020 at 9:10 am
I deleted the other article for which you left a correction, whose rosy predictions for the future of mobile interactive fiction quite comprehensively — and embarrassingly — failed to come to pass. I also binned with some other posts on contemporary interactive fiction and my efforts to move it onto mobile devices. Like the music and book reviews that lived here once upon a time, they were out of joint with what this site has become.
April 26, 2020 at 10:40 pm
I am deeply sad that you removed articles from this site. Rewriting history is never a good thing; it’s better to let the good, the bad, the relevant and the irrelevant stand as they were. What would we think if (say) Infocom has deleted Suspended as out of joint with what the company became?
April 27, 2020 at 1:22 am
That is, very literally, what things like archive.org are for.
April 27, 2020 at 8:28 am
As Ross notes, any historiographer of the future who wishes to make a study of this site’s evolution can still access the material in question via archive.org. For the general reader, however, editing and curation do have their value. Nothing dealing with this site’s core topics has been deleted.
April 27, 2020 at 11:36 am
That is true, so far as it goes. But how is anyone even to know that there is even anything to search for? Even now, knowing that there is (or was) a piece with “rosy predictions for the future of mobile interactive fiction” which I would very much like to read, I have no real idea how I would go about finding that on the WayBack machine.
April 27, 2020 at 11:38 am
That said, it is of course your site, to do with as you wish. You owe me nothing — quite the reverse!