RSS

The Wizard and the Princess, Part 2

It’s 1980, and we just bought The Wizard and the Princess. Shall we play?

After the game boots, we find ourselves in the village of Serenia. We are about to set off to rescue Princess Priscilla from the “great and dreadful wizard” Harlin. And so we stride boldly forth, armed with wits and bravery, ready to conquer… the tedious 15-room desert maze that begins immediately outside of town. An hour or so of careful mapping later, we have determined that our path out of this monstrosity is blocked by a snake that refuses to let us pass. Naturally, being the destructive adventuring type that we are, we start casting about for some way to kill it. Perhaps one of those rocks that are scattered throughout the maze. So we try to gather one up… only to be killed by the scorpion that lurks underneath. After trying every nonsensical thing we can think of, we finally call up old Ken and Roberta themselves for a hint, whereupon we learn that we were on the right track to start with. It’s just that there is only one rock in the maze that doesn’t shelter a scorpion, and that we can therefore pick up without getting killed. Since there is absolutely no way to identify this rock, we get to spend the next hour dying and restarting until we find the right one. If we’re not so excited about watching those pretty but monotonously similar desert pictures draw themselves in slowly again and again by this point, perhaps that’s understandable.

In 1993, when the modern interactive-fiction community that still persists today was just getting off the ground, Graham Nelson wrote up a “Player’s Bill of Rights” to begin to codify good adventure-game design practice. Just in its first few turns of play The Wizard and the Princess has managed to violate 4 of 17 rights: “Not to be killed without warning”; “To be able to win without experience of past lives”; “Not to need to do boring things for the sake of it”; and “Not to be given too many red herrings.” In light of that achievement, I started wondering how many in total the game could manage to trample over. Let’s see how we go…

Not to need to do unlikely things. Not long after bashing one snake with a rock, we encounter another pinned beneath a rock (snakes and rocks obviously figure prominently in this stage of the game). This new snake is presumably as dangerous as the last, and judging from our handling of the first one we aren’t exactly fond of our scaled cousins — but that doesn’t stop us from kindly freeing the snake from his predicament. Turns out he was king of the snakes, and even has a magic word to give us in thanks! (What I’d like to know is just what sort of reptilian royalty manages to get itself stuck under a rock in the first place. Are the snake proletariat classes in revolt?)

Not to depend much on luck. Our encounter with the kindly snake was an anomaly. Pretty soon there’s another chasing us around wanting to kill us. We have to find a stick in another location in the desert, then hit the snake on the head with it to drive it away (an image I find strangely hilarious). If the snake should (randomly) appear at the wrong place or the wrong moment, though, we won’t have time to do that — and it’s curtains for us through no fault of our own.

To have a decent parser. Further on in this endless desert, we discover a couple of notes just lying about, as is common in deserts everywhere. Both are known simply as “note”; the parser apparently randomly selects one when we try to interact with a “note” while both are in our current location. The only way to consistently work with one or the other is to keep each in a separate location entirely. Stuff like this makes me want to write this right in all capital letters, like this: TO HAVE A DECENT PARSER, DAMN IT!

Not to be given horribly unclear hints. Yet further on in the desert we come to a deep, uncrossable chasm. We have to enter the magic word “HOCUS,” whereupon a bridge materializes. I’m not exactly sure how the player is expected to divine this word, but my best guess is that one is supposed to somehow extract it from the contents of one or both of those notes I just told you about, and which are shown above. The one on the left kind of looks like “HOCUS,” doesn’t it? Maybe, if you squint just right? Of course, even if we make that intuitive leap we still have to go around typing “HOCUS” literally everywhere, until something finally happens. But by now the game has already pretty thoroughly ground our right to be exempt from “boring things” into dust with its best jackbooted thugs, hasn’t it?

To have a good reason why something is impossible. We escape the mainland to a small island via a rowboat we find handily lying about. Having dealt with the usual inanities there, there comes a time when we are ready to leave. It might seem natural to use the rowboat that brought us there to travel onward, but that’s impossible. Why? I don’t know — the game just tells us, “I can’t go in that direction.”

To be allowed reasonable synonyms. We are actually expected to travel on using a potion of flight. (We can only figure out exactly where on the island to use it by drinking it over and over again, once in every room, restoring after each experiment. But by now a sort of Stockholm-Syndrome-esque complicity has set in, and we just accept that and go to work with a sigh.) The perfectly natural noun “potion” is not accepted here. We can only “DRINK VIAL” (an interesting thought…) or “DRINK LIQUID.”

To be able to win without knowledge of future events. Moving on, we encounter a peddler offering what appear to be a pair of boots, a dagger, a wine jug, a magnifying glass, and a trumpet for sale. We have just one gold coin, and no idea which of these items we’re likely to need. So we have to save the game and start buying them one by one, each time moving on into the game looking for a puzzle we can solve with that item or the dead end that indicates we must have chosen wrong. And no, the peddler doesn’t have a trade-in policy.

To be able to understand a problem once it is solved. At long last we come to the wizard’s castle. We’re confronted there by a closed drawbridge. It turns out that the correct solution to this problem is to blow the trumpet we bought from the peddler — there’s that question answered, anyway. I recognize some allusion to a returning knight blowing his horn to alert the castle of his return. But why should this work for us, the wizard’s enemy? Shouldn’t blowing the trumpet rather bring a fireball down on our head? And who opens the drawbridge? Certainly no doorman greets us inside. Or is it a magic trumpet? But if it’s a magic trumpet that gives one access to his stronghold, why the hell did the wizard give it to the peddler? Or did he lose it, and the peddler just sort of found it by the roadside? The world will never know…

Inside the castle, our showdown with the wizard is one of the most anticlimactic finales ever. In lieu of the wizard himself, Roberta presents us with yet another enormous, empty maze. (At least the game, in ending as it began, manages a sort of structural unity.) We never even see him as a wizard, only as a bird he has for some reason chosen to transform himself into. Luckily we have a magic ring that briefly turns us into a cat — if we mess around with it long enough to figure out we need to rub it, not wear it, that is — and that’s that.

And Nelson’s other player’s rights? “Not to have the game closed off without warning,” “Not to have to type exactly the right verb,” and “To know how the game is getting on” are violated so thoroughly and consistently by the game that there isn’t much point in belaboring them.

Not to need to be American to understand hints. This right was born from Nelson’s loathing for one particular puzzle, the infamous baseball diamond of Infocom’s Zork II (about which more when we get there); hence its unusual specificity. I think it can be better reframed as a prohibition against requiring too much culturally specific knowledge of any stripe. The Wizard and the Princess manages to not offend too deeply here, although there is one point where, having escaped from the mainland to a tropical island via a rowboat we found handily lying about, we have to give the cracker we found in the desert (amazing what turns up in the desert, isn’t it?) to a parrot. While not exclusively American, I believe the old “Polly want a cracker” meme is confined to the English-speaking world.

To be given reasonable freedom of action. Within the boundaries of the primitive parser and world model, the player does have reasonable freedom. It’s mostly freedom to hang himself, but still… freedom isn’t free, or something like that.

Without these last two, then, we are left with a solid 15 out of 17 potential violations. Not quite a perfect run, but a damn good effort.

So, having had my bit of fun, it’s time to say a few things. Some might regard it as a poor sport to so thoroughly rip apart one particular offender in an early adventure-game scene that was absolutely full of them. Roberta was after all, like other early designers, working without a net, with no received wisdom about good design practice, and with extremely primitive technology to boot. It’s a valid enough charge. The only defense I can offer, which is not really a defense at all, is that I feel particularly unforgiving toward Roberta because she just kept on doing this sort of stuff throughout her almost 20-year career, long after excuses about received design wisdom and technology ceased to hold water. And, having spent so much time with old-school adventures over the past six months, perhaps there did come a point where I just had to vent. Certainly this has been a complete violation of one of my normal policies for this blog, to always try to see the works I analyze in the context of their times. Maybe it’s a good idea to get back to that now, and to ask just why players accepted this stuff — to most outward appearances happily — in 1980, as well as what led designers to commit such violence against their players in the first place.

The Wizard and the Princess is even today not totally without appeal. There is something attractive about its fairy-tale whimsy and its sprawling, discordant map. Discounting only ports of the original Adventure, The Wizard and the Princess was easily the largest adventure game yet to appear on a home computer. And then there are of course those pictures, the real heart of the game’s contemporary appeal. Quaintly appealing today, they were a technical tour de force in 1980, a reason to call family, friends, and neighbors over to the little Apple in the corner to just marvel. Owners of early home computers had had precious little immediately impressive to show off on their machines, just lots of blocky monochrome text showing the strangled English of Scott Adams or cryptic numbers and programming statements. Now they had something impressive indeed. Just as every generation considers its music to be rife with timeless classics and the music of the following generations to be worthless trash, every generation of gamers loves to accuse those who follow of being interested only in flashy graphics and sound. Well, guess what… every generation of gamers has always been interested in flashy graphics and sound. It’s just that this one had precious little of it available to them. If they had to find it in a game that has come to seem almost a caricature of obstinate old-school text adventures, so be it.

That said, there were gamers who reveled in the difficulty of games like The Wizard and the Princess. Some not only accepted balky two-word parsers but considered them part of the fun. In their view, solving a puzzle was a two-step process: figuring out the solution, and figuring out how to tell the computer about it. There was often an odd sort of machismo swirling around in these circles, as gamers who complained about obtuse gameplay were labelled as “not real adventurers.” To what extent this hardcore was rationalizing as a way of accepting the games they were stuck with anyway and to what extent they really, honestly liked guessing the verb and trying literally everything everywhere I’ll leave to you to decide. So much of gaming in this era was still in an aspirational phase, asking players to imagine that the primitive bundle of frustrations they were playing then was already the immersive interactive story everyone could see out there on the horizon, somewhere off in the future. Perhaps that begins to explain the curious sanguinity of everyone during the adventure game’s heyday, manifested in the refusal — still present in the nostalgic even today — to ever cry foul. But then the computer press was not terribly critical of any software, being bound up with the publishers as they were in a web of mutual self-interest. I know that as a kid who loved adventure games — or at least the idea of them — during the 1980s, I was frequently infuriated by the reality. I don’t think I was alone.

And the designers? Much of what led to designs like The Wizard and the Princess — the lack of understood “best practices” for game design, primitive technology, the simple inexperience of the designers themselves — I’ve already mentioned here and elsewhere. Certainly, as I’ve particularly harped, it was difficult with a Scott Adams- or Hi-Res-Adventures-level parser and world model to find a ground for challenging puzzles that were not unfair; the leap from trivial to impossible being made in one seemingly innocuous hop, as it were. However, some other pressures might not be immediately obvious. Consider that Ken and Roberta sold The Wizard and the Princess for $32.95. For that price, they needed to reward gamers with a good few hours of play. Yet there was a sharp limit to the amount of content they could deliver on a single floppy disk and a 48 K computer. (The Wizard and the Princess may have been an unusually big game by 1980 standards, but you can still easily get through it with a walkthrough in a half hour — and most of that time is spent waiting on pictures to load and draw themselves.) The obvious solution was to make the game hard, so gamers would be forced to spend literally hours scrabbling after each tiny chunk of actual content. Later, as piracy became more and more of a problem, some designers perhaps began to see almost unsolvable puzzles as a solution of sorts, for that way they could still get the pirates to buy hint books. Sierra itself stated repeatedly in the later 1980s that its hint-book sales often exceeded the sales of their associated games. What it neglected to mention, unsurprisingly, was the obvious incentive to produce unfair games this created, to earn some money even from the pirates and increase profits overall.

The real danger of bad design practice, whether born of laziness, greed, or simple rigidity (“that’s just the way adventure games are”), is that players get tired of being abused and move on. And if other genres begin to offer compelling, even story-rich experiences of their own, that danger becomes mortal. Through the 1980s designers had a captive audience of players entranced enough by the ideal of the adventure game and the technology used to bring it off that they were willing to accept a lot of abuse. When that began to change… But now we’re getting way, way ahead of ourselves.

For now, suffice to say that, whatever its failings, The Wizard and the Princess became an even bigger hit than Mystery House had been. Softalk magazine’s sales chart for that September already shows it the second biggest selling piece of software in the Apple II market, behind only the business juggernaut VisiCalc. It remained a fixture in the top ten for the next year, eventually selling over 60,000 copies and dwarfing the sales (10,000 copies) of Mystery House. By the end of the year, Ken and Roberta had a number of other products on the market under the On-Line Systems label, and had rented their first office space near their new home in Coarsegold. The long suffering John Williams gave up his promising career as the world’s first software distributor rep to become On-Line Systems Employee #1, where his annual salary amounted to about what he had been earning in a month with the distribution operation. In a very real way, The Wizard and the Princess made the company that would soon go on to worldwide success as Sierra Online.

If you’d like to try The Wizard and the Princess yourself, I have a disk image here that you can load into your emulator of choice. We’ll be leaving On-Line Systems for a while now, but we’ll drop in on them again down the line, at which time I promise to try not to treat their other works quite so harshly.

Next up: another group of old friends we met in an earlier post.

 
 

Tags: , ,

The Wizard and the Princess, Part 1

Mystery House had been an experiment, done on the fly and on the cheap, to see whether there was enough money to be made in computer games to justify jumping in with both feet. Within days of the game’s release, the answer was plainly a resounding yes, and Ken and Roberta started working on systematizing the process and beginning a whole line of On-Line Systems “Hi-Res Adventures.” As Roberta sketched out a design — this time a more typical fantasy adventure, albeit one more inspired by fairy tales than Tolkien — Ken worked like mad to pull together a set of tools capable of implementing not just the next adventure but many more to come. Hackers love their tools, after all, and whatever his loyalty (or lack thereof) to the hacker ethic of elegant software as an idealistic end unto itself, Ken was no exception in this regard. Like Scott Adams before him, he coded a reusable adventuring engine, keeping the data that made up the new adventure separate from the interpreter that made it come alive — a move that would pay off in spades soon enough, when On-Line Systems began expanding its reach beyond the Apple II platform.

But most of all he devoted his attention to the thing that had made Mystery House stand out from its peers, its graphics. He and Roberta had been able to get away with the crude black-and-white sketches in that game thanks to the novelty factor, but the next game had to look better. He therefore set to work implementing a color drawing program to replace the clunky old VersaWriter-based system that had sufficed for Mystery House.

As I’ve mentioned before in this blog, before designing the Apple II or even Apple I Steve Wozniak had designed the Breakout arcade game for Atari. That experience came to shape the Apple II, for Woz, in his usual endearingly quirky way, took the ability to play an acceptable game of Breakout as a sort of baseline expectation for his new machine. This requirement was the main reason that the Apple II’s unique hi-res mode came to exist at all. Woz even made sure the machine’s BASIC had commands enough to make it possible to implement Breakout entirely using only BASIC statements. And Woz’s Breakout fixation was also the reason that a pair of paddle controllers shipped with every single Apple II and Apple II Plus — after all, they were what the arcade Breakout used.

Given the fact that every Apple II owner automatically had a pair, paddles became the standard method of control for early arcade-style games on the platform, limiting as they could sometimes be. Joysticks remained for years a somewhat pricy and unusual novelty — to such an extent, in fact, that Ken designed his new drawing system to use paddles rather than a seemingly more appropriate joystick. With one paddle controlling the X-coordinate and one the Y, the user could (with a bit of practice) draw and fill pictures right on the screen. Perhaps more usefully than its supremely awkward free-hand modes, Ken’s software also functioned as a structured drawing system of sorts, letting the user connect points on the screen with straight lines. One could even draw box sides in a similar fashion. Combined with another program, also of Ken’s devising, that let one draw and edit using Apple’s official graphics tablet, Ken and Roberta now had a downright state-of-the-art graphics workstation by the standards of 1980. Even better, they also had a couple more products to sell; Paddle Graphics and Tablet Graphics were hanging in stores in the usual Ziploc bags even before the game they had been written to create hit the scene.

Said game appeared in September, a scant four months after Mystery House, under the name The Wizard and the Princess. In light of all Ken’s other activities and the technical challenges he and Roberta had to overcome to create it, that time scale is almost unbelievable, but there you are. Those who plunked down their $32.95 and rushed home to boot the disk were greeted by this:

Your reaction to the screenshot above may just be determined by how long you’ve been following this blog. If you’re a relative newcomer, you’re probably pretty nonplussed. If you’ve been reading since the beginning, though, following me through the black-and-white worlds of teletype text and the TRS-80, the monochrome utilitarianism of Temple of Apshai, and the not-quite-monochrome (but don’t you wish they were in lieu of those ugly splats of color?) naivete of Mystery House‘s pictures, you just might, if you’ve taken our time traveling to heart, feel some shadow of the awe that all those Apple II owners felt in 1980. This was stunning, stunning stuff, easily the most impressive graphical display that had yet graced an Apple. And this was Ken’s philosophy that a game should have “wow” factor, should sell itself if someone just booted it up inside a computer store, put into perfect practice.

If you’re not feeling it so much, don’t feel too bad. Actually, what you see above is not quite what players were seeing on their monitors in 1980. All of those tiny pinpricks of color stand out distinctly on our too-perfect modern digital displays. On a real Apple II monitor with its analog circuitry, however, those individual pixels tended to blend together, producing something that looked more like this:

In fact, Ken was relying on exactly this phenomenon to produce the illusion of many more onscreen colors than the Apple II’s official 6. It’s a technique known as dithering. In the sales literature for The Wizard and the Princess, as well as those paint programs used to help create it, On-Line Systems claimed that Ken’s dithering technique effectively increased the number of possible colors from 6 to 21. It’s an effect that is lost on us when we play through emulation — and therein lies the lesson that, while emulation is important in its own right, sometimes we need real hardware to fully appreciate the software artifacts we study.

So, as a demonstration of graphical technology The Wizard and the Princess was truly a stunner. When we look at it as a game, the situation is, as with Mystery House, a bit more… complicated. We’ll get into that next time.

 
 

Tags: , ,

On-Line Systems is Born

Once Roberta sold Ken on the idea of Mystery House, he — typically enough, given his personality — threw himself into it. In just one month during which Ken continued to hold down a day job, the couple implemented Mystery House in its entirety, including the design, writing, illustrations, and programming (in 100% assembly language for speed and efficiency, during an era when even most commercial software was still unashamedly coded in BASIC). Now they had to decide what to do with it.

When Scott Adams created Adventureland almost two years earlier, virtually all microcomputer software was marketed directly by the programmers / entrepreneurs who had created it, through advertisements they made themselves and placed in computer stores, user groups, and magazines and through semi-professional organizations like the TRS-80 Software Exchange. Thus, Adams had little choice but to cobble together packaging using business cards and baby-formula liners and have at it. Now, though, publishers — not least Adams’s own Adventure International — were rapidly professionalizing microcomputer software. The industry was still small, but it was growing rapidly, giving creators like Ken and Roberta with a novel product more options. The biggest of the publishers in the early Apple II market was called Programma International. (One of the amusing aspects of these early publishers is their fondness for the aspirational “International” even though their industry still existed almost exclusively inside the U.S.) In addition to a nice selection of tools for programming and productivity, Programma also published plenty of games. They instantly saw the potential of Mystery House when Ken and Roberta showed it to them. They offered a 25 percent royalty, promising the couple could easily earn $9000 on the game by the end of the year.

Ken and Roberta said no thanks. To understand why, you have to remember what kind of person Ken was — ambitious, driven, and unashamedly focused on the proverbial bottom line. He had already registered a company called On-Line Systems when he started planning that FORTRAN compiler. Why not sell it themselves, and keep all the money? To make the idea even more attractive, a friend of his had a simplistic little shooting game called Skeet Shoot that he was willing to let Ken market. With two actual products to sell, On-Line Systems was born in earnest in May of 1980. Figuring what was good enough for kidnappers and serial killers was good enough for them, Ken and Roberta made some advertising fliers by cutting letters and words out of magazines, pasting them onto backing stock, and photocopying the lot. With 100 blank disks, Ziploc bags for packaging, and a couple of magazine advertisements, they were in business.

A few months ago I poked a bit of fun at Scott Adams for claiming credit on his website for “starting the entire multi billion dollar a year computer game industry.” The funny thing is, in a sense Ken and Roberta Williams could make a much more supportable claim to exactly that. Let me explain.

Having decided to go it on their own, Ken and Roberta’s first sales tactic was to visit every local computer store they knew to demonstrate their products. Luckily, there were quite a few of these; Ken and Roberta were living at the time in California’s Simi Valley, close to the sprawl of Los Angeles. Ken also called his younger brother John, at university in Illinois, to do the same there. John knew nothing about computers, and was very surprised to find that Ken’s new product was a game of all things, for he considered Ken a “chronic workaholic” who “didn’t have a fun bone in his body.” As he described in the tenth-anniversary issue of Sierra’s in-house magazine, John was soon traveling the country hawking On-Line System’s wares to computer stores:

When I visited a computer store, be it in Peoria, Illinois or New Orleans, Louisiana, the game was a hit. Never mind that I had to hand the game disk to the retailer I was trying to “sell” the game to because I didn’t know how to boot a game disk from BASIC. I always walked out of the store with an order. It seemed that Roberta and Ken had written a game that all those Apple owners out there (of which we knew there were at least 50,000) definitely wanted to play.

At this time, dozens of software publishers were either born or birthing, and some 1200 computer stores were doing business around the country, eager for programs to sell to their customers. What was missing was some means of connecting the two groups — in other words, distributors. Software companies like Adventure International were forced to accept orders directly from hundreds of individual retailers. An online profile of software distributor Merisel describes the problems this created:

In 1980 the computer software industry was in its infancy. Programs were written primarily in one-person shops by computer junkies, who did it more for love than for money. Getting this software to the 1,200 or so owners of computer retail stores was, at best, a hit-or-miss affair. If the software writer went on vacation, for example, the factory was closed and shipments stopped. Deciding which software to buy was even trickier. Approximately 95 percent of personal computer software was being sold by retail dealers, but few were in a position to evaluate and select stock from the huge number of programs available.

Ken, a keen business mind if ever there was one, forged connections with Adams and many other publishers to begin distributing their games to retail. (I’m almost certain this is the source of the odd claim that Adams made while being interviewed for Jason Scott’s excellent Get Lamp documentary — and repeated by Jason in an earlier comment on this blog — that Ken Williams somehow got his start with Adventure International as a “salesman.”) Within months, feeling overwhelmed with trying to run a software publisher and a software distributor and be a developer, Ken sold the distribution operation to Robert Leff, a colleague he knew from his years as a programmer for hire, for the uncharacteristically low price of just $1300. Leff in turn built the operation into SoftSel, a behemoth that came to dominate the retail software market behind the scenes, capable of making or breaking a publisher or even computing platform by the titles it chose to accept and the commitment it showed to them. Leff, a name few people outside the software industry knew even then, became one of the most powerful figures in the 1980s computing world. (SoftSel changed its name in 1990 to the aforementioned Merisel.)

There is a certain tang of the bittersweet to this progress. By setting up SoftSel, Ken and Leff effectively ensured that future hackers would not realistically be able to do what Ken and Roberta, Scott Adams, Lance Micklaus, and so many others had done, building viable businesses out of their kitchens and garages on nothing but new ideas and a talent for hacking. Eventually the grip held on the industry by distributors like SoftSel and the huge, conservative publishers that they aided and abetted would come to be blamed for the lack of innovation in and seemingly perpetual adolescence of the whole field of computer and video gaming, a state of affairs that has only begun to be satisfactorily remedied in recent years with the rise of online distribution. At the same time, though, the rapidly growing software industry of 1980 simply needed a SoftSel to get software efficiently into the hands of ever growing numbers of consumers in those days of 300-baud modems and primitive telecommunications. In seeing this need and taking steps to meet it, Ken may have done more to shape the future than he would in all his future efforts with On-Line Systems (soon, of course, to be renamed Sierra). Chalk it up as the last huge step toward the professionalization of software, with all the good and bad that that implies.

Chalk it up also as another example of Ken’s savvy. Other than Bill Gates, I don’t know of another figure in the early PC world who combined such technical acumen with such an instinct for business. His influence is made all the more remarkable when one considers what a late starter he was in comparison to his peers, not getting into the game as he did until 1980. And believe me, there’s more significant stuff that Ken’s fingerprints are all over… we just haven’t gotten there yet.

But back to Mystery House, which was doing pretty well in its own right. Steven Levy writes, “Ken and Roberta made eleven thousand dollars that May. In June, they made twenty thousand dollars. July was thirty thousand.” (And remember, these are 1980 dollars.) Around that time Ken quit his day job, and the Williamses began preparing to pull up stakes and fulfill a lifelong dream — to live in the country, specifically the little town of Coarsegold, not far from Yosemite National Park. Meanwhile, having included their home phone number with Mystery House, both spent hours on the phone doling out hints and advice to frustrated players.

In the midst of this frenzy of activity, Ken and Roberta were also working hard on a new game to consolidate On-Line Systems’s position in the industry. Mystery House had changed everything by having pictures, but, let’s face it, they weren’t really very nice pictures. Their next game would change that by adding color to the equation.

 
 

Tags: , , ,

Mystery House, Part 2

Mystery House has been widely canonized as the “first graphic adventure.” To evaluate that claim, our obvious first step must be to decide just what a “graphic adventure” actually is.

Today, the term is generally taken to refer to mouse-driven games in which the user clicks hotspots on an image of her avatar’s surroundings to manipulate the environment. That’s more of a default configuration than a definition, though; other paradigms for interaction have been and still are sometimes taken to fall under the category. So, we need to do better. We have to be particularly careful in deciding just where the boundary between the text and the graphic adventure should lie. A few years on from the point we’ve made it to in this blog (1980), many text adventures would be available that offered up occasional pictures to accompany their textual descriptions. Whatever they added, these pictures were not interactive, and in fact often completely optional; the purist could simply turn them off and play in pure text with no consequences. Games like these are better termed illustrated text adventures than graphic adventures. The latter term implies that the graphics should be essential to the experience, not a mere ancillary add-on. In fact, that’s a pretty good start on a definition right there. Let’s further add that the graphics should be interactive, subject to manipulation by the player rather than mere storybook-style illustrations. So, let’s try this:

A graphic adventure is a form of ludic narrative which bears many similarities to the text adventure (or interactive fiction), favoring puzzles and story development over reflex-oriented action. However, the player and the program communicate with one another primarily through images rather than text. These images should be interactive — subject to manipulation by the player — and essential to the experience of the work.

Given those requirements, my first instinct was to pooh-pooh the idea of Mystery House as the first graphic adventure when I recently picked it up again after many years. It was, I thought, obviously the first illustrated text adventure — a significant development in its own right — but at heart it was still “merely” a text adventure. Boy, was I wrong. It actually leapfrogs over the logical next step — the illustrated text adventure — to do something much more audacious. Much of the core of the game does indeed play out not in text but in pictures.

Let me show you what I mean. Here we are at the beginning of the game, having just walked into the entry hall of the mansion.

That note (helpfully labeled “NOTE” in giant letters) at the bottom left is not described anywhere in the text; we know it is there only through the picture. Now, look what happens when we pick it up.

It disappears! These are not mere static images, but genuinely interactive graphics. When we read the note, the results once more appear not in the text but in the graphics area.

If we take the note somewhere else and drop it, sure enough, it appears again in the scene.

Easy as it might seem to laugh at the scrawled, stick-figure pictures themselves, this was remarkable, remarkable stuff for its time. The Williams are prototyping here a whole new paradigm for adventuring while even the text adventure was still in its relative infancy. The novelty of the technology on display here alone was sufficient to generate many thousands of sales.

And that’s fortunate, because the game itself is no better than it ought to be given the inexperience of Roberta. It’s allegedly a mystery story, but it’s an oddly static mystery; as soon as we depart from the entry hall for the first time, five of the seven people we saw there are immediately distributed around the house as dead bodies, giving us no chance to avert any of the deaths. We can only hunt around through the typical adventure-game secret passages and mazes until we arrive at the final confrontation with the obvious murderer; in no sense do we “solve” the mystery at all, unless by process of counting up who is alive and, in the climax, who tries to kill us. The Count, still the gold standard for dynamic ludic narrative at this time, has nothing to fear. As if herself doubtful of her choice of genre, Roberta even shoehorns in the treasure-hunt subplot alluded to in the note shown above to move us back onto more traditional adventuring ground. The effect of this is to make Mystery House a cold-blooded, even morbid little game that’s blackly humorous in its absurdity. We wander around discovering corpse after corpse, but in finest adventure-game-protagonist fashion never let them deter us from hunting for those jewels.

The graphics make possible annoyances that are worse than typical for even this era, including perhaps the cruelest maze that had yet been seen in an adventure game. Even “normal” navigation is a constant struggle; the game’s instructions tell us that north is usually up on the screen, south down, etc., but it then proceeds to violate that guideline literally from the very first picture we see. The result is that we never feel entirely sure which way we’re facing, and thus never can orientate ourselves properly. Not that it would necessarily do much good; this is a classic adventure-game house in which nothing aligns properly with anything else, like a creation of a Victorian architect with an M.C. Escher fetish.

The dining room is a particularly noteworthy chamber of horrors.

That object on the table is a candle, drawn a bit roughly but identifiable I suppose. That triangular… thing… on the back wall is supposed to represent a hole in the wall which for no apparent reason contains a crucial key. If we try to interact with the hole while carrying the lit candle or matches, we promptly trip, set the carpet on fire, and die if we don’t happen to be carrying a pitcher of water or cannot figure out in a single turn the syntax needed to use it on the fire.

Oh, and in this case north is left and south is right, not that it’s possible to determine this through anything but trial and error.

A major “puzzle” has us MOVing a cabinet in the kitchen for no apparent reason, and even though the game has stubbornly disclaimed knowledge of that verb up to this point.

After burrowing through the bricked-up hole that is revealed, we inexplicably find a fresh murder victim in the disused old secret passage beyond. Mimesis is not strong with this one.

So, no, Mystery House is not a very good game. In fact, it’s a sometimes hilariously bad collection of the worst adventure-game cliches. In light of its pedigree and its very real formal innovations, though, I’ve probably already harped on its many failings too much. Most of its contemporaries weren’t much better, and they weren’t also inventing a whole new paradigm of adventure gaming while they were about it. (I can, however, fault Roberta for continuing to design similarly bad puzzles long after she should have known better — but that’s material for later posts.)

If you’d like to experience Mystery House for yourself, I’d definitely recommend you treat it as an artifact of history rather than a serious gaming or narrative experience in its own right. In other words, use a walkthrough so you can laugh at its absurdities rather than cry. The easiest way to play it is via Java through the Virtual Apple II website.

 
 

Tags: , ,

Mystery House, Part 1

When we left Ken and Roberta, they had just made the momentous decision to use the Apple II’s bitmap graphics capabilities to create an adventure game that featured pictures in addition to text. Roberta would be the first to admit that she was no artist, but she was up to creating some sketches that would suit the purpose; in a world with no graphic adventures at all, people after all wouldn’t be too inclined to criticize the aesthetics of the first one to appear. Still, pulling it off would require them to overcome two other challenges: how to get the pictures into the Apple II in the first place, and how to store them in such a way that they didn’t consume too much space on disk. This latter problem arose because Ken and Roberta were determined to provide pictures for every single location in the game, amounting to some 30 illustrations in all.

Creating pictures on the Apple II was a dicey proposition in early 1980, due not only to a dearth of usable paint programs but also to the lack of a suitable input device to use with them; mice were still years away, while drawing with a joystick, trackball, or keyboard was an inevitably sloppy, frustrating process. Ken and Roberta therefore ended up purchasing an ungainly contraption called a VersaWriter.

The VersaWriter was far too persnickety to allow for free-hand drawing. The user was rather expected to insert a sketch under the transparent surface of the drawing area, and then to trace it using the stylus. The device was marketed as a tool for getting diagrams — flowcharts, circuit diagrams, floor plans, etc. — into the Apple II; its packaged software did not deal very well with the irregular lines and patterns typical of full-blown pictures. Apple itself had actually released a drawing tablet much more suitable for illustrations the previous year. Apple’s tablet, however, cost $650, while the VersaWriter could be had for less than $200. Still uncertain about this whole enterprise and desiring to do it on the cheap, Ken went with the VersaWriter. Now he needed to find a way to make it work. Like a good hacker, he promptly set to work writing his own software to operate it. In doing so, he actually solved his second challenge almost accidentally.

Storing 30 or more images on disk as simple grids of pixels would consume far more space than Ken had available on a single disk. If he wished to avoid the hassle of shipping the game on many disks and asking the user to swap among them, he needed to find a better way. With compressed graphics standards still unheard of (and likely too taxing on the little Apple’s 6502 if they had been), Ken hit upon the idea of storing each picture not as the data that made up the final product, but rather as a series of drawing commands that could be used to create it afresh. In other words, instead of being fetched from disk, the pictures in Mystery House are “drawn” anew by the computer each time they appear. (Or, for the more technically inclined: they are stored as vector graphics, not raster graphics.) The really elegant bit is that the drawing statements used to create them correspond with the motions of the stylus that traced them on the VersaWriter. Thus to store his graphics Ken needed only “record” the motions of the stylus as it traced Roberta’s simple drawings, then “play back” those motions on the screen when called for in the game. It’s a masterful little hack, one that shows how far Ken had come as a programmer from his days as a drone-in-training at Control Data Institute.

Combined with a simple parser and world model about on the level of the Scott Adams games, the final product looked like this.

No, the graphics aren’t exactly lush. If you can bear with me getting just a bit technical for a moment, it makes a great exercise in platform studies to ask just why they look like they do.

The Apple II’s normal “Hi-Res” graphics mode provides a bitmap display of 280X192 pixels. The programmer can, however, optionally choose to reserve the bottom 32 pixels of the screen to display the bottom of the Apple II’s regular text screen, which lives elsewhere in memory. This mode proved perfect for a game like Mystery House, as well as plenty of others soon to come from On-Line Systems and others. Because the text screen persists elsewhere, one convenience feature is very easy to program: the player can, just by hitting enter on a blank input line, make the picture disappear, revealing her last several turns.

Another tap of the enter key instantly restores the hi-res overlay, which has remained in memory. This was quite slick stuff in 1980, and the Apple II makes it trivial. It’s perfect for a game like Mystery House, almost as if Wozniak had anticipated this application when he designed it.

But, you might be wondering, why the bizarre coloration in the illustrations? To answer that, we need to look a bit more deeply at the way that hi-res mode works.

A bitmap graphics display is normally stored in memory as a long string of bits which are constantly fetched and painted to the screen. The exact amount of memory needed for the purpose obviously depends on the resolution of the display. But slightly less obviously, it also depends on the number of colors in our palette. If we allow just 2 colors (probably black and white), we need but one bit for each pixel. If we want to allow more, though, we need more memory. A 256-color palette, for instance, requires 8 bits, or 1 byte, to store each individual pixel. You are probably reading these words on a 24-bit color screen with a palette of well over 16 million colors, which must devote 3 full bytes to representing every pixel. (This mode is often inaccurately termed 32-bit color because modern hardware is happy to waste one full byte on every pixel to keep things aligned in a tidy way.)

Numbers like these were, of course, inconceivable in 1980. The Apple II Plus offered just 6 colors in hi-res mode. If you apply what you learned back in Computer Literacy, you can quickly conclude that we would need to devote 3 bits to each pixel to store an Apple II bitmap in the conventional way. (Using 3 bits actually gives a range of possible numbers between 0 and 7, which is overkill; 2 bits, however, is too few.) Let’s do a quick calculation: 3 bits per pixel * 280 horizontal pixels * 192 vertical pixels = 161,280 bits, or (dividing by 8) 20,160 bytes (a bit under 20 K). Now consider that we have 48 K of memory total available on the Apple II; devoting almost half of it to the display is untenable if we also want to be able to write programs of any complexity at all to actually take advantage of hi-res mode.

These realities weren’t lost on Wozniak. As in so many other areas of the Apple II, he came up with a way to do more with less. Rather than devote 3 bits to each pixel, he devoted just 1 — but reserved one bit in each byte for a special purpose, about which more in a moment. Then he defined a set of simple rules to determine what color each pixel would be. If a bit is not set, the pixel it corresponds to on the screen is also “off,” or black. If a bit is on, and the bit to either its left and/or its right is also on, that pixel appears as white. If a bit is on, is on an even x-coordinate, and the adjacent bits are both off, that pixel appears as violet or blue, depending on whether that eighth, reserved bit is set or not. A bit on an odd x-coordinate in the same situation follows the same rules to arrive at a green or orange pixel. This setup allows us to store a 280X192 6-color screen using only 7680 bytes. It brings with it, however, a collection of restrictions:

  • A white pixel must have at least 1 other white pixel to its left or right. (In other words, a vertical white line drawn on the screen must be at least 2 pixels wide.)
  • A pixel on an even horizontal coordinate can allegedly be white, black, violet, or blue, but not green or orange. If, however, the bit in question is off, and a colored pixel is adjacent, that color “bleeds over” to color in this supposedly black pixel.
  • Similarly, a pixel on an odd horizontal coordinate can allegedly be white, black, green, or orange, but not violet or blue, subject to the same process as above.
  • Each horizontal line consists of 280 pixels, but these are divided into 40 groups of 7. Pixels within each group can be violet or green, or blue or orange, but combinations are not allowed. (In other words, a single group of 7 cannot contain both violet and blue, green and orange, etc., pixels.)
  • For any given pixel to be colored black onscreen, at least one bit adjacent to the bit in memory that represents it must also be black. (In other words, a black vertical line like a white vertical line must always be at least 2 pixels wide.)

With all that in mind (and yes, I know it hurts), we realize it’s perhaps more accurate to say that the Apple II has a horizontal resolution of just 140 pixels, since each pixel’s color is controlled so thoroughly by the pixel adjacent to it. And given that combined with what a royal bitch the hi-res mode was to work with for programmers, it’s worth asking whether this whole baroque scheme is really worth the headache. Woz’s tendency to produce stuff like this in the name of efficiency is one of the more problematic aspects of a generally brilliant engineer. (Remember, Atari had to redo Woz’s Breakout design because no one else could figure it out. This fact, legendary as it has become as a sort of proof of Woz’s genius, might reflect more poorly on him than it does on Atari’s engineers from a certain point of view…) Have a look at the image above once again. Notice how the vertical lines are all in green or violet, while the horizontals are in white? Ken could only have made those vertical lines white by doubling their thickness, and throwing all of the proportions off. The Apple II literally does not permit the simple black-and-white sketches he really wants to display. Crazy stuff, huh?

These odd patterns of coloration, not to mention the distinctive pastel tones of the colors themselves, make an Apple II display, then as well as now, instantly recognizable to anyone who’s spent any time at all with one. While its display is unusually idiosyncratic, the Apple II is by no means alone here. Displays from most early microcomputers exhibit telltale traces of their origin. It’s one of the things that make these old machines so appealing to some living in our modern world of anonymous technological perfection. Call it personality, or, if you must, call it soul.

Which doesn’t, of course, mean that contemporary users didn’t struggle like mad to find ways to overcome basic limitations like these. More on that later. But next time, we’ll see how Mystery House actually plays as a game, and ask what it means in historical context.

 
 

Tags: , ,