RSS

Category Archives: Digital Antiquaria

Ultima, Part 3

You may have noticed that I haven’t heretofore said much about what the ultimate goal of Ultima is, beyond collecting gems and statistics. That’s because for the most part the game hasn’t said much about it either; all we know is that it’s something to do with a time machine. After drinking in a pub, it all finally comes out in an infodump that is downright epic by this game’s standards, as well as amusing for the way that Garriott gradually drops the fiction of the bartender entirely to just tell us directly how it is.

BUB, YOU SHOULD KNOW THAT OVER 1000 YEARS AGO MONDAIN THE WIZARD CREATED AN EVIL GEM. WITH THIS GEM, HE IS IMMORTAL AND CANNOT BE DEFEATED. THE QUEST OF ULTIMA IS TO TRAVERSE THE LANDS IN SEARCH OF A TIME MACHINE. UPON FINDING SUCH A DEVICE, YOU SHOULD GO BACK IN TIME TO THE DAYS BEFORE MONDAIN CREATED THE EVIL GEM AND DESTROY HIM BEFORE IT’S [sic] CREATION. IF YOU DO THIS, YOU WILL SAVE THE UNIVERSE AND WIN THE GAME!!!

Doing this would of course introduce a veritable moebius strip of paradoxes. Nor does the land feel particularly oppressed at the moment. Granted, there are roving bands of monsters everywhere, but, hey, I’m in a CRPG, and anyway they’re mostly bears and giant squids and that sort of thing, not really your typical evil minions. I’ve yet to see Mondain or his minions at all, and the kings all seem benevolent enough if we are willing to overlook the princesses they have locked up in their dungeons. And hey, who hasn’t had a princess or two locked up in their dungeon at one time or another? Still, we have our quest. Time to get on with it.

We also learn some other things in the pub:

BUB, YOU SHOULD KNOW ABOUT SPACE TRAVEL! AND THAT YOU MUST DESTROY AT LEAST 20 ENEMY VESSELS TO BECOME AN ACE!

BUB, YOU SHOULD KNOW THAT THE PRINCESS WILL GIVE GREAT REWARD TO THE ONE WHO SAVES HER, AND AN EXTRA GIFT IF THE PLAYER IS 8TH LEVEL OR GREATER!

Reading between the lines here, we need to reach 8th level (already done), become a space ace (?), and then rescue yet another princess. So, what the hell… we buy a space shuttle, and park it next to the “air car” we’ve had for a while now, a vehicle that looks suspiciously like Luke Skywalker’s landspeeder.

Okay, what is going on here? In Garriott’s own words:

The earliest Ultimas really were an amalgamation of everything I thought was cool in the few books that I’d read, the many movies I’d seen, and the few other games that I’d played — all thrown into one game. It was pretty much anything goes.

So, D&D and fantasy in general were cool. In they went. Star Wars was cool. In it went. Garriott’s astronaut father was soon to fly into space again aboard the space shuttle, and that was really cool. In it went. In addition to all of the pop-culture influences, these early Ultima games are filled with Garriott’s family, friends, and acquantances — and of course Garriott himself in the person of not only Lord British but also his normal SCA character, the more understated ranger Shamino. When some scholar of the future studying this pioneer of ludic narrative creates an Annotated Ultima, she’ll have a goldmine of references to illuminate.

But as for us, we’re going into space now to try to become a space ace. The space parts of Ultima introduce a whole new sub-game, added by Richard out of a self-proclaimed desire to pack as much onto its two disk sides as he possibly could. Obviously editing was not, at this stage at least, Garriott’s strong suit. That said, the space game is more complex and satisfying than one might expect, if as limited in its potential for fast action as one might expect given its BASIC implementation. Our first task is to safely dock our shuttle — which for some reason no longer looks quite so much like the NASA space shuttle as it did on the ground — to a space station.

With that accomplished, we can choose a more combat-appropriate vessel and begin to hyperjump from sector to sector on the trail of enemy ships. We do need to keep an eye on our fuel supplies whilst doing so, returning from time to time to a station to top off. And exactly how does this relate to Mondain? Sigh… I really don’t know. I suppose it’s possible that the enemy ships belong to his forces — although they look, inevitably, like TIE fighters.

So, we finally shoot down our 20th TIE fighter and return to Sosaria as a space ace, primed for the climax. We dutifully rescue our umpteenth princess. This time she tells us about a time machine “far to the northwest.”

We go there in our trusty landspeeder…

We activate the time machine, a process described with another unusually long string of text:

UPON ENTERING THE CRAFT, YOU FIND FOUR HOLES MARKED R, G, B, AND W. YOU PLACE THE PROPER GEMS IN EACH. YOU SEE A BUTTON MARKED LAUNCH. FURTHER EXAMINATION LEADS YOU TO NOTICE THAT YOU ARE LOCKED IN… NOTHING TO DO BUT LAUNCH?!?!

AFTER ONLY A FEW MOMENTS, YOU FEEL A STRONG MAGIC PULLING YOU FROM THE CRAFT. A MOMENT LATER…

…YOU FIND YOURSELF FACE TO FACE WITH MONDAIN HIMSELF. GOOD LUCK, THIS IS IT!

And the final showdown begins…

There’s actually a somewhat unfair trick to this final battle, the only such in the entire game. We can pound on Mondain endlessly — by this point he’s really not that dangerous to us — but he will keep coming back to life on us. We need to move over to that little ball sitting next to him, which represents his “EVIL GEM,” and pick it up using a command, G for “Get,” that we’ve never had occasion to use in the entire game to his point. This is all somewhat at odds with what Garriott — I mean, the bartender — told us was supposed to be happening here. We were supposed to be traveling back to a time before Mondain made the gem, not taking it from him and destroying it. Ah, well. We finally figure out what the game expects of us, and prevail at last. It all ends with a message that would become another of the Ultima series’s trademarks, albeit later games would ask us to report our victory to Lord British directly rather than his flunkies at California Pacific.

I’ve spent quite a lot of time in these posts poking fun at Ultima. At times it’s kind of hard not to; the game plays like exactly what it is, a catalog of one particularly bright nerd’s rather typically nerdy interests, circa 1981. Yet that’s also exactly what gives the game its charm as well as its time-capsule quality. I’m sure a few of us were similar kids once upon a time, and hopefully we won’t ever completely outgrow our sensawunda. There’s an openhearted quality about Ultima; it wouldn’t know irony if it walked up and bashed it for 1000 hit points. Yes, that makes it easy to make fun of, but that also makes it kind of lovable. And I’d be remiss not to point out that, in an era rife with horribly designed adventure games, Ultima is, that one misstep at the end aside, remarkably fair. If Zork hates its player, Ultima just wants us to have a good time, and it’s willing to throw in everything up to and including the proverbial kitchen sink to make sure that happens. “And hey, there’s a princess to rescue, and a spaceship to fly, and these really cool monsters to fight, and the dungeons are in, like, 3D…” God bless its innocence.

Ultima‘s charms were rewarded with some very impressive sales by the standards of the still small entertainment software market: 20,000 copies sold in its first year. Still, Garriott, who had led a charmed existence thus far, was about to run into his first real complications.

But next time: something a bit less innocent than Ultima.

 
8 Comments

Posted by on February 15, 2012 in Digital Antiquaria, Interactive Fiction

 

Tags: ,

Ultima, Part 2

As anyone who’s ever played an Ultima can tell you, our first step upon beginning a new game must be to seek out the castle of the in-game version of Lord British. Unlike in Akalabeth, shown to the left above, castles in Ultima are implemented as little navigable worlds of their own, complete with king, guards, jesters, and even a handy princess awaiting rescue; in the image below I’m standing at the bottom right, just outside her cell.

Every castle, like every town, is identical except for its name and the king we find there. Like in Akalabeth these kings provide us with direction for the bulk of the game in the form of quests, a welcome design choice that helps Ultima, again like Akalabeth, avoid the sense of aimless needle-in-a-haystack wandering that plagues so many other early adventure games. In Ultima, we can also opt for “gold” instead of “service” when speaking to a king, meaning we can trade cash for hit points.

Here I have to take a moment to talk about this game’s, um, unusual approach to character building. Hit points here are a collectable resource awarded by the game or bought from kings, with no relation to anything else about your character. There is, in other words, no maximum total of hit points to which you can be healed and, indeed, no real concept of healing at all. You simply earn hit points questing or buy them from kings, and spend them fighting monsters. And that’s just the beginning of the strangeness. The game provides a running total of experience points, but I haven’t been able to actually determine what they do for you. In a Republican’s fever dream of a socialist dystopia, leveling up is simply a function of hours spent on the job; every 1000 turns earns you another level. (There’s actually no variable at all in the code assigned to your character’s level; the game just divides time by 1000 every time it needs to print your level.) And then there’s the game’s oft-remarked obsession with food: you consume a little bit with every move, and if you ever run out you die — instantly. I kind of like what one Ophidian Dragon said about Akalabeth‘s food system, which worked the same way: “It’s like you have a gigantic bag of potato chips on your back, and are constantly munching on them, and when the bag is empty you instantly die!” Such absurdities are sometimes necessary to make of a piece of ludic narrative a playable game, but the mechanics of this and later Ultimas are often suspect not just from a narrative but also from a game-design perspective. The joy of Ultima is more in exploration and discovery than in strategizing. In other words, Ultima is no Wizardry (and vice versa — and if you don’t know what I’m talking about, well, we’ll be getting to Wizardry soon).

After leaving Lord British, we head for the nearest town — Britain, natch — to stock up on supplies. Like the castles, the towns are now implemented as navigable environments of their own, albeit once again all identical. There’s an unusually off-color element here in this otherwise asexual world: if we drink too much at one time in a pub (in best D&D fashion, a necessary source of hints and tips about goings-on), we get seduced by the local wench, who gives us a “long night” but takes all our money in return. I suppose you get what you pay for. (And apparently our character is a heterosexual man. Good to know.)

More productively, we need can pick up some new armor and weapons. Trouble is, we’re not exactly flush with cash. Luckily, there’s the handy “Steal” command. But if we get caught, the whole town goes apeshit and comes after us. So we do what Ultima players have been doing for time immemorial: save our game outside town (the only place saving is allowed), then enter and try our luck. With a bit of patience if not much fidelity to the game’s fiction, we eventually equip ourselves with plate armor and a blaster. “Wait,” I hear you say, “a blaster? Like a Star Wars blaster?” Just hold off; we’ll get to that.

Incidentally: in one of those user-interface choices that make these early games such a delight, we steal by pressing “S.” We’re thus pretty much guaranteed to do lots of accidental stealing when we really want to “sell,” at least until we’ve gotten it pounded into our little heads that the command for selling is actually “Transact.” And don’t even get me started on “Klimb,” or the immortal “Ztatistics” command.

Journeying onward, we spend some time killing monsters outdoors to build up our cash reserves and test out our ill-gotten hardware. Then we visit the Castle of the Lost King and accept our first quest: to kill a gelantinous cube. Doing so requires venturing into a dungeon. And doing that in turn brings on a case of deja vu: the dungeon-delving part of Ultima has been left unchanged from Akalabeth.

Well, I say unchanged, but it sure feels like it’s gotten even slower. Most of one’s time underground is spent watching the screen lugubriously redraw itself. A few of Mr. Arnold’s assembly-language routines would have been welcome here. In between redraws, we fight a mixed bag of monsters, many of them, like the gelantinous cube we’re after for this first quest, drawn straight from the D&D Monster Manual. (A quick way to guess whether a given monster is drawn from some mythology or fiction or original to D&D: the more ridiculous it is, the greater the chance of the latter.) The gelantinous cube is kind of annoying in that it’s really, really hard to see against the walls of the dungeon itself.

It’s also kind of annoying in that it eats our armor when it hits us successfully. We could carry nine or ten suits of plate mail with us for occasions just like this (no sniggering on how ridiculous that is!), but, thanks to a bug or Garriott’s just never having gotten around to it, it’s actually impossible to equip new armor while in a dungeon. Sigh.

So, by this point the structure of the game begins to become clear. There are eight castles to be visited, arranged, in that symmetric way so common to made-up worlds, two to a continent. Four of the kings — you guessed it, one per continent — send us on quests to kill progressively more dangerous monsters at progressively lower dungeon levels. When we complete each of these quests, each king gives us a gem, and also babbles something or other about a time machine.

The other four send us to seek out above-ground landmarks, but only raise our strength score in return. (The landmarks themselves raise our other statistics.) Of course, all is not as easy as it sounds. Unlike the later games, Ultima shipped with no map of its world, meaning just finding all of the castles and landmarks requires quite a bit of patient, methodical exploration. At least our searching expends the turns needed to gain levels, a good thing considering we need to get to at least level 8 to finish the game.

One thing we can do to speed our development is to rescue princesses. Note the plural; there’s one in every castle, and since each castle is reset as soon as we leave it we’ve got an effectively infinite supply of damsels in distress. Exactly why these presumably benevolent kings are keeping the poor princesses under lock and key is never adequately explained. Indeed, Sosaria is not so much a world as a shadowy projection of the possibility of a world, onto which we can graft our own fictions and justifications. Or not: as we’ll soon see in the context of the princess as well as other things, there are plenty of signs that Garriott doesn’t take it all that seriously himself.

Rescuing a princess first involves killing — yes, killing, in cold blood — the jester who is helpfully yelling, “I’ve got the key!” every few turns. After that the castle guards go predictably apeshit, while we check our “Ztats” to see whether we got the key to Cell #1 or Cell #2. In the former case, we can only run for it — or restore a saved game — and try again. In the latter case, we can effect our rescue. In the screenshot below I’m at the extreme left edge, just making my escape with the princess and most of the castle guards hot on my heels. My reward is 3000 hit points, 3000 gold pieces, and 3000 experience points. Not bad.

Now, there’s so much about this game that it so ridiculous that’s it’s hardly worth flying into a rage about the moral shadiness of all this. I do want to be sure to point it out, however, because Garriott would later have something of an epiphany after taking a hard look at the many situations like this in his own works and decide to stand up for morality. But that’s a story for another time.

We eventually acquire the fourth and final gem by killing a “balron,” a creature that in Akalabeth was named after the balrog of Gandalf-killing fame. As the game industry grew in size and public exposure, Garriott and other designers slowly found themselves having to be more careful about the niceties of copyright law. He even made some efforts in Ultima to rename some of the obviously D&D-inspired monsters; the carrion crawler, for instance, becomes the “carrion creeper.” Anyway, Garriott’s balron looks more like a kid in an angel costume than Gandalf’s “foe beyond any of you.”

Notice in the screenshot above the ridiculous number of hit points we’ve bought by this point.

With the balron dispatched, we’re about to move past the mushy middle toward the climax. And things are about to get weird. We’ll try to finish up next time, if we can manage to find a plot. I’m pretty sure there’s one around here somewhere.

 
8 Comments

Posted by on February 13, 2012 in Digital Antiquaria, Interactive Fiction

 

Tags: ,

Ultima, Part 1

When we left Richard Garriott, California Pacific had just released his first game, Akalabeth, a substantial windfall for the 19-year-old university student. In between classes and SCA events, he spent his sophmore year at the University of Texas writing a new, much more ambitious game, which CP published just as the spring semester of 1981 was wrapping up. I think we can best proceed by just diving right into the game that retroactively came to be known as Ultima I.

Like Zork, making Ultima available here presented a bit of an ethical dilemma for me. You can actually now buy the first three Ultima games again via Good Old Games, a service I can hardly applaud enough for keeping deep catalog works like these in print in a form easily runnable on modern PCs. However, the version they sell is the Origin Systems remake from 1986. It’s much more polished and playable than the original that Garriott wrote in BASIC on his Apple II Plus, but it’s of course also something of an anachronism for a digital antiquarian like me. So, I’m going to go ahead and offer here the original California Pacific Ultima as Apple II disk images along with the original accompanying documentation, at least until someone tells me not to. If you’re following closely along with my journey into the game, or want to do some digital archaeology of your own, have at it. If, on the other hand, you’re a bit less hardcore but your interest is piqued enough to want to give Ultima a shot, by all means go for the much more playable and accessible version you’ll find on Good Old Games — no emulator required.

By the standards of later Ultimas, the packaging of Ultima I is spartan: the two disks, a very to-the-point 10-page manual, and a player reference card that, oddly, includes important information not included in the manual (and vice versa). No lengthy books of lore, no cloth maps, no ankh medallions. Yet by the standards of its time, in which games were just transitioning from Ziploc baggies to more professional packaging (a symptom of the slowly encroaching professionalization of the industry as a whole), it’s a fairly generous production. More ephemerally, this first Ultima experience feels like the CRPG experience that so many fans would come to know over the next decade, the era Matt Barton calls the “Golden Age” of the CRPG: a big experience promising many hours of adventure from its garishly illustrated outside to the multiple disks found inside. (In fact, Ultima is the earliest game I know of to spill across more than a single disk side.) And that impression stems from more than just the details of its presentation. If Zork in some sense perfected the text adventure by hitting upon a robust approach to interactive fiction that still persists to this day, Ultima, one could argue, did much of the same for the CRPG. Like Zork, Ultima is perhaps the first example of its form that one might actually want to play today just to, you know, play. So let’s boot our Apple II and have at it, shall we?

Until very shortly before its release, Ultima was not called Ultima, but rather Ultimatum. We can see evidence of this by listing the directories of the disks themselves; the file holding the title screen you see above is still titled “PIC.ULTIMATUM.” Why choose that name? Like so much in Garriott’s early games, simply because it sounded cool; certainly this title has no more bearing on the game’s plot, such as it is, than does the name Ultima. The change was made when Garriott and California Pacific discovered that there was already a tabletop war game in print under the name Ultimatum. Wishing to avoid confusion and legal complications, it was Al Remmers of CP who suggested that they shorten the name to simply Ultima because, once again, it sounded cool. (Later apologists’ attempts to construe the name as a reference to the semi-mythical classical land of ultima Thule are about as convincing as their attempts to construct a coherent narrative arc out of the random smorgasbord of plot and setting of the first three Ultima games.) Remmers, you may remember, also suggested that Garriott take his occasional nickname Lord British as his nom de plumme, drumming up a promotional campaign for Akalabeth depicting Lord British as a reclusive and enigmatic genius. It’s ironic that Remmers, a guy that Garriott didn’t know that well and with whom he would soon have an ugly falling out, essentially created the two brand names for which Garriott will forever be remembered, while he himself faded quickly into obscurity. It’s also emblematic of the uncanny luck that seemed to follow young Garriott around, luck which brought various older and (possibly) wiser men to further his career almost in spite of himself. Remember also John Mayor, his ComputerLand manager who convinced him to sell Akalabeth in the store and by some accounts was responsible for bringing it to the attention of Remmers and CP…

Just like Akalabeth, Ultima — shown on the right in the comparison above — dumps us into an overhead view of the outdoor landscape after we create our character. Unlike in Akalabeth, we now have monsters to contend with out here as well as in the dungeons. And if Ultima is still not exactly a graphical extravaganza, things sure do look a whole lot better than before, thanks largely to the game’s major technical innovation: tile graphics.

Ultima‘s world is a pretty big one, spanning four continents each many times the length and width of a single screen. At a resolution of 280 X 160, trying to draw all of this at the level of individual pixels would be untenable, both technically (even two disk sides couldn’t possibly store that much information) and practically (Garriott was just one guy, and not really an artist either; nor was the the Apple II’s library of graphics software terribly mature by this point). The solution was to draw the world using a collection of pre-rendered tiles, each 14 X 16 pixels. Each screen is thus formed from 200 of these tiles, in rows of 20 and columns of 10, laid together in a process that would feel kind of similar to doing a jigsaw puzzle or playing a tile-laying board game like Carcassonne. Ultima‘s world map is represented on the computer as just a grid of numbers specifying which tile should be slotted into which position by the graphics engine. It’s often claimed that Ultima represents the very first application of this technique that was soon everywhere in videogames of the 1980s, one that still crops up more than you might expect even today. Being a skeptical bastard by nature, I do wonder that no one thought of it in even the relatively brief history of videogames prior to Ultima; it does seem a fairly obvious approach, after all. On the other hand, I can’t point to a specific example that would give me grounds to really challenge the claim. As always, post ’em (or comment ’em) if you got ’em.

Ultima‘s tile-graphics engine was not so much the work of Garriott as of a friend of his who was the only other person to have a significant role in the game’s design and implementation: Ken W. Arnold (not the Ken Arnold who created Rogue). A neighborhood chum of Garriott’s, Arnold worked at the same ComputerLand store where Garriott spent that fateful summer of 1980. The two sketched out the initial plan for the game together when Garriott, excited by the sale of Akalabeth to California Pacific and beginning to realize he could make money at this stuff, began work on Ultima even before leaving again for university. Arnold not only invented the tile graphics scheme but also handled the technical implementation, writing an assembly-language routine to fetch the tiles and rapidly paint them onto the screen as the player moves about the world. This routine, along with another to generate the game’s simple combat sound effects, were the only parts of Ultima not to be written in BASIC. Garriott, unlike Arnold, had not yet learned assembly language, and thus implemented everything else in BASIC after leaving Arnold, Houston, and ComputerLand to return to university in Austin.

Even with the tile system, creating Ultima‘s graphics was a challenge. From The Official Book of Ultima:

“We had to actually enter all the shapes in hex,” Garriott says, detailing the primitive process. First he and Arnold would draw them out on graph paper, then convert the graphs to binary, which in turn had to be reversed because the pixels appeared on the screen backwards. After converting it into hex, they entered the tile as data, stored it on disk, and then ran it to see if it looked right on the screen. “We had no editors or anything, so it was a very painful thing.”

Indeed, one suspects that, even in the context of 1980-81, easier ways could have been devised. Put another way, young Richard and Ken had not yet learned the value of making programs to make programs. Still, stories like the above illustrate one of the most remarkable things about these early games of Garriott’s: they were created by a self-taught kid who literally figured things out as he went along, working on a single Apple II and with none of the technical background or resources of an Infocom or even an On-Line Systems or Muse to call upon. Their ramshackle technological underpinnings may be less elegant than the Z-Machine, but they are in their own way just as remarkable. In very real sense it’s amazing that Ultima exists at all.

The world all of their labor lets us explore is based upon Garriott’s latest Dungeons and Dragons campaign world circa mid-1980, which he called Sosaria; he literally transcribed his D&D maps right into the game. As we’ll soon see, Sosaria is not exactly the most coherent of milieu. A person could also say that gameplay has not progressed all that much beyond Akalabeth: we still move around the wilderness map to visit towns (for our shopping needs), castles (for quests), and dungeons (for critter bashing). One is reminded once again of Garriott’s joking comment that he spent some 15 years making the same game again and again. The person who said Garriot hadn’t progressed much would be pretty unfair, however, because much has changed here too. Virtually everything is now bigger and more fleshed out, and there’s a big overarching quest to solve. In fact, the whole philosophy of the game has moved from the Akalabeth approach of being a relatively short, replayable experience to the extended, save-game-enabled epic journey CRPG fans would soon come to associate with the name Ultima.

 
5 Comments

Posted by on February 10, 2012 in Digital Antiquaria, Interactive Fiction

 

Tags: ,

Robot War, Anyone?

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

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

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

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

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

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

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

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

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

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

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

 
 

Tags: , ,

Robot War

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

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

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

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

The screen on which you’re reading this is almost certainly a bitmapped display. This means that it is seen by the computer as just a grid of colored pixels. The text you’re reading is mapped onto that grid in software, “drawn” there like an unusually intricate picture. This is a cool thing for many reasons. For one, it allows you to customize things like the size, shape, and style of the default font to suit your own preferences. For another, it allows writers like me to play with different typefaces to get our message across. It’s a particularly nice thing for word processing, where a document on the screen can be rendered as a 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: , ,