Tag Archives: mystery house

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.

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.

There are two prototypical kinds of “computer professionals” in the world. First there are the purist hackers, who dive into the depths of circuits, operating systems, and programming languages like explorers discovering new lands; it wasn’t by chance that away from the computer Will Crowther was a caver, nor that he now spends his time deep-sea scuba diving. For the purists the reward is in the thing itself, in learning to understand and navigate this binary wonderland and maybe, just maybe, someday making (or helping to make) something really, truly new and cool. The other group is made up of the careerists. These people end up in the field for some mixture of a variety of reasons: because they need to earn a good living to support their family (no shame in that); because they’ve heard computers are cool and the next big thing (hello, Internet bubble); because they have a vision of society which requires computers as its enabler (hello, Steve Jobs); because they just want to get really, really rich (why, there’s Steve again hiding out in the corner hoping not to be noticed — hi!). One thing only binds this disparate group together: they are attracted to computers not by their intrinsic interest in the machines themselves but by externalities, by a vision of what the machines can do, whether for them or for others. The two groups often seem — and believe themselves to be — at odds with one another, but in truth they need each other. Witness the dynamic duo of Woz and Jobs that built the Apple II and got it to the masses. Or witness Ken and Roberta Williams, the power couple of 1980s adventure gaming.

Ken and Roberta married in 1972. He was just 18 at the time; she was 19. He was attending California Polytechnic Pomona University as a physics major, and failing; she was living at home and not doing much of anything. Contrary to what you might be thinking, there was no shotgun involved. He simply wanted Roberta in his life and was determined to have her there, permanently. Steven Levy writes that his words to her were simply, “We’re getting married, and that’s it.” She “didn’t fight it.” Right there you learn a lot about their two personalities.

Within a year or so of their marriage Ken, a restless, driven, somewhat aggressive young man with no real respect for or interest in higher education with its hierarchical structure and its abstract theorizing, could see he wasn’t going to make it as a physics major, much less a physicist. Roberta, meanwhile, was now pregnant. Ken needed a career, and he needed one quick.

In the early 1970s the institutional computer industry was nearing its peak, supplying mainframes and minicomputers by the thousands to businesses, universities, public and private schools, branches of government, and research installations. We’ve met several of the prominent companies already (IBM, DEC, HP), each serving their own core sectors of this huge market while competing with one another on the margins. Another was Control Data Corporation. Founded in 1957 by a group of refugees from an even earlier company, Sperry, CDC had by the early 1970s carved out a reputation for itself as a manufacturer of prestigious and expensive supercomputers of the type used for some of the most intensive scientific computing. The supercomputer market was, however, a small one, and so the bulk of CDC’s business was courtesy of its line of more plebeian mainframes that competed directly with IBM for corporate business. To carve out a place for itself against the larger company, CDC tried to stick to a “10% rule”: to make sure each of its systems was always 10% faster and 10% cheaper than the nearest equivalent IBM model. For a number of years this approach was very good to CDC, sufficiently so that the company opened a little trade school all its own to train future custodians of its systems. Armed with a $1500 student loan co-signed by a very concerned father-in-law, Ken entered Control Data Institute. In doing so he was conforming to a stereotype that remains with the computer industry to this day: the pure hackers go to universities and get computer-science degrees; the careerists go to trade schools and get certificates in something “practical.”

Indeed, the atmosphere at Control Data Institute promised nothing like the free-wheeling intellectual exploration of the computer-science labs at MIT or Berkeley. The emphasis was on pounding in the rote tasks and procedures needed to maintain and run the big, batch-processing mainframes of CDC at the banks and other large bureaucratic entities that housed them. And that suited Ken, hungry for a career in business, just fine. Where an MIT hacker might have seen intolerable drudgery, he saw money to be made. When he turned out to be pretty good at this computer stuff — even within limits to enjoy it — that just increased the earning potential.

After finishing at CDC, Ken spent the rest of the 1970s living a life that we more typically associate with the following decade, bouncing from company to company in search of ever better salaries while generally also juggling two or three independent consulting gigs on the side. With computers still mysterious, almost occult objects to most people, a fast-talking, energetic, and ambitious young man like Ken could go far with just the modicum of knowledge he had gained at CDC. As that knowledge increased and he became an ever better programmer and problem solver courtesy of the best teacher of all, experience, he seemed even more of a miracle worker, and found himself even more in demand. Ken, in other words, was becoming a pretty damn good hacker almost in spite of himself. But he always wanted more — a new hot tub, a bigger house, a nicer car, a place in the country — even as he dreamed of retiring young and bequeathing a fortune to his children. (These things would in fact happen, although not in the way Ken thought they would in the 1970s.) Ken made no apologies for his materialism. “I guess greed,” he later told Levy, “would summarize me better than anything. I always want more.”

When the first kit computers that one could build in one’s home appeared in 1975, Ken barely noticed. There was no real money to be made in them, he believed, unlike his big, boring mainframes. When the trinity of 1977 marked the arrival of a PC you didn’t need a soldering iron to assemble, he likewise paid no attention. It was not until a couple of years later that the beginning of a real, paying market in professional business software, exemplified by pioneering applications like VisiCalc and WordStar, made Ken begin to pay attention to the little “toy” machines. When he finally bought an Apple II in January of 1980, it was for a very specific purpose.

At the time there were only two real language possibilities for Apple programmers: they could use BASIC, which was easy to learn and get started with but quickly became a nightmare when trying to structure large, complex programs; or assembly language, which gave the ultimate in precise control over the hardware but was well-nigh impenetrable for the uninitiated, tedious in the micro-management it required, and just as bereft of structure. Ken saw an opportunity for a more sophisticated high-level language, one designed to be used by serious programmers creating complex software. Specifically, he wanted to bring FORTRAN, as it happens the implementation language of the original Adventure (not that Ken likely knew this or cared), to the little Apple II. With that purpose in mind, he registered a company of his own, choosing to call it On-Line Systems, a name fairly typical of the vaguely futuristic, vaguely compound, but essentially meaningless names (Microsoft, anyone?) that were so common in the era.

And what was Roberta doing during these years? Well, she was raising the Williams’ two children and happily (at least to external observers) playing the role of housewife and homemaker. She had always been a painfully shy, passive personality who by her own admission “could hardly make a phone call.” If Ken seemed to already be living in the frenetic 1980s rather than the mellow 1970s, Roberta seemed a better match for the 1950s, the doting wife who took care of the children, made sure everyone in the family had a good breakfast, lunch, and dinner, and meekly entrusted the big decisions and the earning of a living to the man of the house. That makes what happened next doubly surprising.

Shortly before Ken bought that first Apple, and while the Williams’ second son was just eight months old, Ken happened to have a remote terminal at the house for one of his gigs. The mainframe to which it could connect had on it a copy of Adventure, which by now had been ported to a variety of other platforms beyond the PDP-10. Ken called Roberta over to have a look at what he regarded as nothing more than a curiosity. Roberta, however, was immediately transfixed. “I started playing and kept playing it. I had a baby at the time, Chris was eight months old; I totally ignored him. I didn’t want to be bothered. I didn’t want to stop and make dinner.” As Ken wondered what had become of his dutiful wife, Roberta stayed up most of the night playing, then lay awake in bed working through the puzzles in her mind. It was no doubt a relief to everyone when she finally finished the game after a month of effort.

But the respite didn’t last long. After Ken brought the Apple II into the home, it didn’t take Roberta long to learn about the works of Scott Adams. Soon she was back to obsessively playing again. But then another thought began to crowd out the conundrums of the games: what if she could make a text adventure of her own? She was turning the most inspirational corner I know, imagining herself as a creator rather than a passive consumer. Inspired mostly by Agatha Christie’s novel Ten Little Indians and the board game Clue, she began to sketch ideas for a text adventure as cozy murder mystery, a genre that the form had not yet tackled. When she was pretty far along, she took a deep breath and laid out her ideas to Ken.

The story concept was certainly innovative, but it wasn’t the sort of innovation that would immediately appeal to a guy like Ken, with little interest in game design in the abstract. He was rather interested in products he could sell, operating intuitively by a rule he would later, for better and perhaps sometimes for worse, codify and articulate regularly: “Games have to have ‘WOW-value.’ If you don’t say ‘wow’ when someone describes the game to you, or you see it from 10 feet away, there’s no reason to market the game.” At first, caught up in his FORTRAN software and his prior experience of computers only as serious tools of business, he was dismissive of Roberta’s little project. But as she persisted, and as he perhaps began to notice that companies like Adventure International were growing rapidly and making real money just like the “serious” software houses, he began to reconsider. Still, he needed something special, needed an angle to help their little game stand out from the likes of the established line of Scott Adams games.

He began to think about the Apple II, with its comparatively cavernous 48 K of RAM, its fast and reliable disk drives, and its bitmap graphics capability. What if he designed their game around the unique capabilities of that machine, instead of taking the portable lowest-common-denominator approach of Adams? And then came the brainstorm: he could use the Apple’s hi-res mode to include pictures with the text. That would certainly make their game stand out. Pretty soon FORTRAN was forgotten, and work on Mystery House (the first of a whole line of On-Line Systems “Hi-Res Adventures”) had begun in earnest. The husband-and-wife team were not that far removed from Woz and Jobs. Here, Roberta designed the thing out of her inherent fascination with the thing itself, while Ken enabled her efforts, providing the tools and support she needed to bring her vision to life and, soon enough, finding ways to sell that vision to the masses.