RSS

Monthly Archives: August 2011

A Busy 1980

When we last left Scott Adams at the end of 1979, he was poised to take this adventuring thing to the proverbial next level, with a solid catalog of games already available on a number of platforms, with perhaps the best name recognition in the nascent computer-game industry, and with a new company — Adventure International — ready to publish his works and the works of others under its own imprint. The following year saw him realize all of that potential and more, to take a place at the forefront of a new industry.

Adventure International grew by leaps and bounds for the next few years, while always remaining, like everything Adams touched, indelibly stamped with the personality of its founder. AI was the Dollar General of the early software industry. Its catalogs are filled with a ramshackle collection of software of every stripe. In addition to the expected text adventures from Adams and others (many of these also using Adams’s engine), there were arcade clones (“far superior to any Space Invader game for the TRS-80 microcomputer so far”, announces the blurb for Invaders Plus, with more honesty than legal wisdom); space strategy games (Galactic Empire and Galactic Trader); chess programs (“although a graphic display of the chessboard is provided, it is recommended that an actual chessboard be used during play…”); board game adaptations (Micropoly, which is once again foolish enough to advertise that it is a clone of Monopoly right in the promotional text); even TRS-80 Opera, which let one listen to the William Tell overture via a transistor radio set in close proximity to the machine’s cassette port (the TRS-80’s lack of proper RF shielding was not always such a bad thing). And for when fun-and-games time was over, there were also math programs, print spoolers, programming tools, drawing programs, and educational software to hand, the latter evincing the usual fascination with states and their capitals that was so common amongst early programmers. All of this software was relatively cheap, with $9.95 or $14.95 being the most common price points, and somewhat… variable… in quality. Still, there was a thrill to be had in walking the virtual aisles of the AI catalogs, gazing at the shelves groaning with the output of an expanding new industry, wondering what crazy (not to say hare-brained) idea would be around the next bend. Hovering over the whole scene was always the outsized personality of Adams himself, who would remain throughout AI’s brief but busy lifetime an unusually visible company leader. (A reading of the legal fine print shows AI itself to be merely “a division of Scott Adams, Inc.”)

The year 1980 represents an important historical moment for the entertainment-software industry. A few exceptions such as Microsoft and Automated Simulations aside, computer games had previously been distributed as a sideline by semi-amateurs who hung their Ziploc baggies up in the local computer store and signed up with the hobbyist distribution services run by SoftSide and Creative Computing magazines. Now, though, companies like AI and a few others that sprung up around the same time began to professionalize the field. Within a few years the Ziploc baggies would be replaced with slick, colorful boxes stuffed with glossy manuals and other goodies, and the semi-amateurs in their home offices and bedrooms with real development studios whose members did this stuff for a living. Computer games were becoming a viable business, bringing more resources onto the scene that would soon allow for bigger and more ambitious creations than anything yet seen, but also bringing all the complications and loss of innocence associated with monetizing a labor of love.

In light of the explosive growth of his company, it’s no surprise that Adams’s creation of new adventures slowed down dramatically at this point. Some of his energy was consumed — and not for the last time — with repackaging his already extant games. All received pen-and-watercolor cover illustrations courtesy of an artist known as “Peppy,” whose colorful if unpolished style perfectly suited the gonzo enthusiasm of Adams’s prose.

AI released just two new Adams-penned adventures in 1980: the Western pastiche Ghost Town in the spring and Savage Island Part One, first of a two-parter advertised as difficult enough for the hardcore of the hardcore, just in time for Christmas. I thought we’d take a closer look at the first of these to see how far Adams’s art had progressed since The Count.

The simple but painful answer to that question is: not at all, really. In fact, it has regressed in many ways. The Western setting was apparently merely the next on Adams’s list of genre touchstones to cover, as it does little to inform the experience of play. Ghost Town is a plotless treasure hunt, just like Adventureland; it’s as if the The Count never happened: “Drop treasures then score.” Sigh.

We rob the saloon of its cash box just because it’s there. Double sigh.

Worse, even as a treasure hunt Ghost Town is neither entertaining nor satisfying. A few quips such as the response to trying to GO MIRROR (“I’m not Alice!”) aside, Ghost Town has lost some of the friendly warmth that made one somewhat willing to forgive the earlier games their own dodgy moments. The useful HELP command with its little nudges and food for thought has disappeared entirely, while the puzzles have devolved into a veritable catalog of design sins. Adams had been slowly ramping up the difficulty of each successive game that he wrote, apparently expecting his player to work through the games in order and thus to be prepared by the time they faced Ghost Town. I suppose that’s a reasonable enough approach in the abstract, but in reality there is no way to train for the puzzles in Ghost Town. Even some of the least objectionable require considerable outside knowledge, of things like the composition of gunpowder or the translation of Morse code.

Of course, in 1980, a time when Wikipedia was not a browser bookmark away, tracking down this sort of information might require a trip to the local library.

Other puzzles require us to see the room in question exactly as Adams pictured it, despite his famously terse room descriptions that do little more than list the objects therein. Still others reward only dogged persistence rather than insight, such as requiring us to tote a shovel around the map and dig in every single room to see whether anything turns up. Yet more, the worst of all, are protracted battles with the parser. How long it would take the average player to divine that she must SAY GIDYUP to get the horse to move is something I don’t even want to think about — nor how long she might fruitlessly try mixing the charcoal, sulfur, and saltpeter together before finally just typing MAKE GUNPOWDER. At times the parser seems not just technically limited but intentionally cruel.

Typing just GUNPOWDER as opposed to WITH GUNPOWDER at the above prompt results in a generic failure message. My experience with Ghost Town makes me more enamored than ever of the idea that these early games were simply too technologically limited to support difficult puzzles that were also fair and logically tenable, that ramping up their difficulty beyond a certain rather low threshold inevitably resulted in nonsense like so many of the puzzles in Ghost Town and the absurd end-game of Adventure.

It’s also tempting to conclude that Adams himself simply lacked the vision to continue to push the text adventure forward. Tempting, but not entirely correct. For a couple of years Adams wrote an occasional column for SoftSide magazine. In the November, 1980, edition he announced a planned new adventuring system called Odyssey, which would take advantage of disk-drive-equipped systems in the same way as did Microsoft Adventure, using all of that storage space as an auxiliary memory store. His plans were ambitious to say the least:

1. More than one player in an Odyssey at one time. Players may help (or hinder) one another as they see fit!
2. Full paragraphs instead of “baby talk,” e.g., “Shoe the horse with the horseshoe and the hammer and nails.”
3. Longer messages;
4. sound effects; and
5. expanded plot lines.

To develop this system I have actually had to develop a new type of computer language which I call OIL (Odyssey Interpretive Language) which is implemented by a special Odyssey assembler that generates Odyssey machine code. This machine code is then implemented on each different micro, e.g. Apple, TRS-80, etc., through a special host emulator to simulate my nonexistent Odyssey computer.

Currently (as of the Washington computer show, Sept., 1980) the system is in the final stages of implementing a host emulator on a TRS-80 32 K disk system and writing the first Odyssey (which has been sketched out and is tentatively entitled Martian Odyssey) in OIL to run on the emulator. I hope that by the time you are reading this, Odyssey Number One will be available from your local computer store or favorite mail order house.

The technical conception of Odyssey sounds remarkably similar to what would soon be rolled out by a tiny Massachusetts startup called Infocom. Interestingly, Marc Blank and Stu Galley of Infocom had laid out in the abstract the design of their virtual machine, the “Z-Machine,” in an article in Creative Computing just a couple of months before Adams wrote these words. Could he have been inspired by that article?

Whatever the answer to that question, Martian Odyssey of course never appeared, and to my knowledge Adams never mentioned the Odyssey system again. For better and (ultimately) for worse, he elected to stick with what had brought him this far — meaning treasure hunts runnable on low-end 16 K computers equipped only with cassette drives. That strategy would continue to pay off handsomely enough for a few more years, yet it’s hard not to wonder about the path not taken, the territory ceded without a fight to Infocom and others. From 1980 on, Adams is more interesting as a businessman and an enabler for others than as a software artist in his own right. On that note, I want to talk about a few of the more interesting creations to stand alongside Adams’s own adventures in the jumble of the Adventure International catalog next time.

If you’d like to try Ghost Town, here’s a version you can load into the MESS emulator using its “Devices -> Quickload” function.

 
 

Tags: , ,

Temple of Apshai

In 1978 a fellow named John Connelley purchased a Commodore PET to aid in the bookkeeping of the Dungeons and Dragons campaign he was running. When he got the thing home and perhaps realized that the 8 K wonder’s utility for such a purpose was limited at best, he was afflicted with a bit of buyer’s remorse at the money he’d spent on it. Since he loved games, he hit upon the idea of writing one for the machine. Even if he didn’t sell enough copies to make any real money, he could at least use the project to justify writing the PET off on his taxes as a “business expense.” Unfortunately, Connelley was a better programmer than a game designer, and so his initial attempts went nowhere. In the end he turned to one of his D&D players, Jon Freeman, for help. Freeman was in just the opposite boat: he had been working for several years as a freelance games journalist and had a strong aptitude for game design, but knew nothing about programming. And so a marriage of convenience was born.

The first fruit of this union appeared before the end of the year in the form of a space strategy game called Starfleet Orion. To release it, Connelley and Freeman formed Automated Simulations, the first software publisher dedicated solely to games. Starfleet Orion looks rather bizarre when viewed through modern eyes, seeming more a sort of ludic construction set than a completed videogame. Its manual lays out an elaborate back story to justify a dozen space-battles scenarios between two alien races. The setup and order of battle for each of these is given, tabletop wargame style, in the manual; as the first step before actually playing one must key all of this data into the program and save it to a blank cassette using a separate program called BUILDER. In a touch that seems particularly bizarre to modern sensibilities, the BASIC source code for the game itself is also given in full in the manual, in case the player wants to tinker or the cassette on which the game is housed gets corrupted. Not only is Starfleet Orion two-player only, but it requires quite a time commitment; the manual estimates the climactic scenario to require about six hours to play, with no provision for saving state. Freeman and Connelley addressed these issues at least somewhat with Invasion Orion, a more accessible sequel with provision for solo play that they released early in 1979.

The really big release of 1979, though, took them out of space and into the dungeon. For Temple of Apshai, they brought in a third partner from their D&D group, Jeff Johnson, to help with an even more ambitious game design. Apshai was to be a full-fledged CRPG, drawing from the PLATO tradition of games like dnd, but also, in keeping with its designers’ background, paying very explicit homage to the deeper tabletop D&D experience that had brought them together in the first place. Its manual opens with a description of experiential gaming that is drawn straight from the tabletop RPG experience:

Role-playing games are not so much “played” as they are experienced. Instead of manipulating an army of chessmen about an abstract but visible board, or following a single piece around and around a well-defined track, collecting $200 every time you pass Go, in RPGs you venture into an essentially unknown world with a single piece — your alter ego for the game, a character at home in a world of demons and darkness, dragons and dwarves. You see with the eyes of your character a scene described by the “author” of the adventure — and no more. There is no board in view, no chance squares to inspect; the imaginary landscape exists only in the notebooks of the world’s creator (commonly called a referee or dunjonmaster) and, gradually, in the imaginations of your fellow players. As you set off in quest of fame and fortune in company with those other player/characters, you are both a character in and a reader of an epic you are helping to create. Your character does whatever you wish him to do, subject to his human (or near-human) capabilities and the vagaries of chance. Fight, flee, or parley; take the high road or low: the choice is yours. You may climb a mountain or go around it, but since at the top may be a rock, a roc’s egg, or a roc, you can find challenge and conflict without fighting with your fellow players, who are usually (in several senses) in the same boat.

Like the Orion games, Apshai foregrounds its experiential aspect. Games such as dnd quickly devolved into abstract exercises in tactics and strategy, with little thought paid to their fictional premise of dungeon exploration. Apshai, however, goes to great pains to try to get its player not to adapt that mindset. It plainly wants us to put ourselves right there in its dank dungeons, through the aforementioned proselytizing introduction; through an extended backstory justifying the existence of the dungeon you explore and describing a character you are free to imagine as your alter ego (“Brian Hammerhand”); and, most notably of all, through a set of D&D adventure module-style room descriptions the player is expected to read from the manual as she explores:

Room One — The smooth stonework of the passageway floor shows that advanced methods were used in its creation. A skeleton sprawls on the floor just inside the door, a bony hand, still clutching a rusty dagger, outstretched toward the door to safety. A faint roaring sound can be heard from the far end of the passage.

Unlike other early dungeon crawl games, whose dungeons were randomly generated or put together so haphazardly that they might as well have been, Apshai‘s dungeons are crafted to feel like a real place, even though that means that its monsters must be limited largely to sewer inhabitants (giant rats, various giant insects) and, on the lower levels that house the temple proper, various undead.

To be honest, all of this experiential gilding can feel a bit ridiculous to modern sensibilities because… well, to start, here’s what the actual game looks like in its original TRS-80 incarnation:

The fact that this display is a bit underwhelming is not the fault of Apshai‘s designers. The TRS-80 was limited to black and white (not gray-scale, mind — exactly two colors, black and white). Further, it wasn’t really capable of graphics at all in the way we think of them today, only character graphics. (In addition to a set of 64 commonly used English glyphs, it includes 64 more graphical tiles, each containing a simple abstract shape in lieu of a character glyph. By combining these together, it was possible to build larger pictures out of what remained essentially a text-only display.)

Viewed in the light of such a display system and the 16 K cassette-based computer on which it ran, Apshai is actually quite a technical achievement. Its rules also bear the stamp of an experienced game designer. They actually do not draw as heavily from D&D as one might expect given the game’s origins and the extended praise of the tabletop experience that fills its manual. While the expected six character attributes are present, and while they even number from 3 to 18 just like in classic D&D, combat and movement is very much its own thing here, a pseudo-real-time system that shows a willingness to harness the unique capabilities of the computer rather than just translate a pen-and-paper rules set into code. In fact, Apshai plays better in some ways than it has a right to; there’s a real tension to navigating through this labyrinth, deciding whether to press your luck and venture onward or turn for the exit, dreading the appearance of the next wandering monster as you do trudge back heavily wounded, having perhaps pressed your luck too far. There’s a visceral feel to the experience that many later dungeon crawls would fail to capture. This quality owes its existence partly to the real-time nature of play, but also to other choices that have no counterpart in tabletop D&D. As your character loses health, for instance, he moves more slowly, gets fatigued faster, and becomes less effective, bringing home his state in a palpable way. Freeman’s design is a very smart one, in many ways very original even in comparison to games that would follow.

But there are inevitable limits to what even a smart designer can do on a 16 K TRS-80. One can easily forgive the fact that magic is not present at all in the game; the player is restricted to playing what amounts to the D&D fighter class. Of more concern is the fact that the two components of the game, the “Innkeeper” which is used for character management, and the “DunjonMaster” where the dungeon delving actually happens, don’t really talk to one another. The player is expected to keep a list of her attributes and the items she finds in the dungeon on each expedition, then enter those manually when she returns to the Innkeeper! Rather than being linked together, the four levels of the dungeon can each only be entered separately; there is absolutely nothing preventing the player from entering a super-character into the Innkeeper and starting out on level 4. There’s not much point to methodical exploration anyway, as there is absolutely no way to really win the game. For all its emphasis on the experiential, one cannot bring Apshai to any conclusion. One merely explores, levels up, and collects until one gets tired of the whole thing.

Still, even dictated as it is by technical limitations, there’s an odd sort of charm to Apshai. Rather than delivering a story, it really does expect its player to work with it, to build a story that exists as much in the imagination as it does in the computer. “Sure, you are free to ‘cheat’ and create a character with stats of all 18,” it says, “but what fun would that be?” Similarly, if the game doesn’t deliver an ending like we’ve come to expect, that doesn’t prevent the player from making up one of her own. There is an encounter on level 4 that feels kind of like a climax — or maybe the player just sets her own goal of visiting every single room and collecting every single treasure. Apshai expects you to work with it to make your own fun. Anyway, as Freeman wrote of a tabletop RPG campaign, “It never stops, except temporarily: there is no final victory, no point to playing except playing, and no ultimate aim except the continuing development of your character.” Why should the computer equivalent be any different? Indeed, if played as its designers imagined Apshai doesn’t really feel like a pure computer game, but some hybrid — a computer-assisted solo RPG rather than a CRPG, if you like.

In an article in Byte magazine, Freeman described the differences between the RPG’s simulational approach to narrative and the text adventure’s preference for set-piece design, while leaving little doubt which he preferred:

There is no real role-playing, for instance, in the Adventure/Zork family: the protagonist is just you in a strange setting. Games of that sort concentrate on the perceived open-endedness of action: not only is there a multitude of command options available (typically far more than Dunjonquest‘s eighteen or so), but also they are not made known to you except by trial and error. It can be quite challenging to find the right key, the right moment, and the right command necessary to insert it in the right lock; but once you do, the door will always open — always. Thus, a game like Adventure is really a puzzle that, once solved, is without further interest.

The Dunjonquest series employs a different approach. For one thing, situations are primarily defined graphically, not textually: you see the situation rather than just being told about it. More to our present purpose, while some Dunjonquest games, like Morloc’s Tower, have a specific object (finding and slaying the mad and elusive wizard Morloc), there is an open-endedness of result in all of them on the micro level (if you’ll excuse a small pun). Generally speaking, there are no “right” answers; the outcome of events is probabilistic, not predetermined.

Brian Hammerhand, the assigned alter ego/protagonist of Morloc’s Tower and The Datestones of Ryn, can, for example, slay a dire wolf nine times out of ten, but on any particular occasion he may survive the encounter unscratched, or limp away badly mauled and out of breath — and there is also that tenth time. Moreover, the exact outcome of any encounter depends both on the tactics you choose and on the specific traits of your surrogate character. The experience is different every time you play and quite different with each new character you take on your adventure. You are role-playing: getting outside yourself and into the skin of another (albeit imaginary) being.

The contention that the simulational approach leads to role-playing while the set-piece approach does not is highly suspect — although we should remember that at the time Freeman wrote this passage IF protagonists were universally of the “nameless, faceless adventurer” type. Still, the tension between the two approaches that Freeman describes here remain with ludic narrative right up to the present, often within the same design. We’ll doubtlessly be revisiting the topic many more times as we continue on this little historical journey.

If you’d like to experience Temple of Apshai for yourself, here are some instructions to get you started. Note, however, that you’ll need the patience of a saint; by modern sensibilities the original TSR-80 version is all but unplayable, what with the sloooooow speed of its screen updates and the aforementioned divide between the two halves of the program.

1. Download my neat little Temple of Apshai starter pack.
2. Start the sdltrs emulator.
3. Press F7, then load “newdos.dsk” in floppy drive 0 and “apshai.dsk” into floppy drive 1.
4. Reboot the emulator by pressing F10.
5. At the DOS prompt, type BASIC.
6. Type LOAD “INN:1”.
7. Type RUN.

The manual and quick reference card in the zipped download above should see you through the rest.

We’ll continue to check in on the developing CRPG in the future, but next time we’ll get back to text adventures, and see what our old friend Scott Adams got up to as the 1980s began.

 
 

Tags: , , ,

The First CRPGs

The CRPG form lacks an Adventure — an urtext universally known and acknowledged as its starting point. I can propose a couple of reasons why this is so.

CRPG fans have, some exceptions aside, generally not shown anything like the same dedication to documentation and historical preservation that marks the modern interactive-fiction community, which has perhaps prevented an accepted canon of historically significant works from appearing amongst the former as it has amongst the latter. Likewise, for all its enduring commercial popularity the CRPG has not acquired the same academic cachet as has IF; it’s easier to justify study of a “literary” form like IF within the academy than it is a form that revolves around killing hordes of monsters and leveling up, no matter how much fun that process might be. Just as significantly, Adventure had the good fortune to become really, really popular. It was the Doom of late 1970s institutional computing, a game that absolutely everyone who spent any time within that culture had to know and probably tried to play at least once or twice. The early proto-CRPGs of the same era, of which there were a fair number, did not spread so widely and did not come to occupy the same storied place in hacker lore. Most were created on a pioneering system called PLATO (Programmed Logic for Automated Teaching Operations — how long did they work to make that acronym fit?), which linked hundreds of educational institutions around the U.S. together via thousands of dumb terminals, a handful of mainframe computers, and a central hub at the University of Illinois.

I could easily devote a whole series of posts to PLATO, the first sustained online community to connect everyday people — mostly students from elementary to university age — together. I’ll just give you the short version here, though, and mention that PLATO was remarkable indeed in many ways, laboratory of countless innovations, from the vision of computer-assisted instruction that spawned it in the first place to the uniquely user-friendly custom operating system it ran to its TUTOR programming language that let anyone design new “lessons.” Uniquely amongst institutional systems, its terminals offered graphics and, if your school had chosen to spring for some additional gadgetry, possibly even some sound and music capabilities. Originating all the way back in 1960, PLATO reached a certain level of maturity with the roll-out of the PLATO IV system in 1972, and grew rapidly in this incarnation throughout the 1970s. Its graphical capabilities made PLATO exceptionally suited for gaming in comparison to other institutional systems, which still generally relied on clunky text-only teletypes for input and output. Throw in the fact that most of these terminals were being used by students with a bit of time on their hands, and that they had the easy-to-learn TUTOR language at their disposal, and it’s not surprising that PLATO became something of a hotbed of game development immediately before the beginning of the PC era and even for some years thereafter. Amongst these games were the first attempts to bring the Dungeons and Dragons experience to the computer. They began to appear as early as 1975 — even before Will Crowther’s creation of Adventure.

The earliest of these games were created without proper authorization from PLATO’s administrators. Thus they had to hide out on the system under unassuming, workmanlike names such as pedit5 and m199h, with word of their existence being passed around in secret. Inevitably, as their popularity increased they attracted the notice of administrators and were promptly deleted. Luckily, what appears to be the original version of Rusty Rutherford’s pedit5 has been restored and made available by the folks at cyber1, a resurrected PLATO system accessible via the Internet.

As the first or second game of its type to appear, pedit5 has a decent claim to stand as the CRPG’s equivalent of Adventure. Certainly it’s of immense historical importance.

That said, the most long-lived and popular of these games, the one that first defined the experience of the CRPG for many in the same way that Adventure did that of the text adventure, came a bit later. Its name left no doubt as to its inspiration: dnd. A much more sustained and ambitious project than the one-off pedit5, dnd was initially written by Gary Wisenhunt and Ray Wood, then expanded and refined by Dirk Pellett. By October of 1976 it had reached a basically finished state, becoming a surprisingly complex experience and a very popular one amongst PLATO users; the counter of total plays was already almost 100,000 at that time.

Dnd spawned a whole family of PLATO dungeon crawls which share their ancestor’s blissful unconcern with copyright. Nowadays the lawyers of the Tolkien estate would be all over Moria and Orthanc.

It might make an interesting little exercise in platform studies to ask why the PLATO system hosted so many dungeon crawls, while text adventures became the diversion of choice amongst the hardcore hackers working on their DEC systems. A good part of the answer comes down to technological constraints: PLATO could do screen-oriented, graphical displays rather beautifully really, while the PDP line continued to rely on line-oriented output devices capable only of text. The broader implications of this for interactive-fiction fans, that gamers have always preferred their pretty pictures and will take them whenever they can get them over plain text, are perhaps too disquieting to dwell on. If it helps, though, it’s also true that the two computing cultures used incompatible hardware and communicated over wholly separate networks, thus keeping these two burgeoning gaming traditions wholly separate from one another before they began to mix in the great melting pot of the PC world. Adventure and dnd after all gave each of these communities, still very small by modern computing standards, plenty of inspiration and plenty to iterate on without leaping into whole other paradigms of play.

Similarly, the most popular platforms of the early PC era, the TRS-80 and the Apple II, initially hosted quite different strains of adventure. Thanks largely to the efforts of Scott Adams, the TRS-80 went in the PDP hackers’ direction to host the first text adventures to enter the home. The Apple II, meanwhile, the only member of the class of 1977 with graphics capabilities even close to those of PLATO, went in the direction of dnd. Given the sketchy documentation and the ad hoc nature of most software “publication” of that era, it’s extremely difficult to say with certainty what game marked the first CRPG to appear on the Apple II — and by extension the first to appear on a home PC. Synergistic Software’s Dungeon Campaign, which appeared right about the time that Adams was shipping off those first tapes of Adventureland, is probably the best candidate.

For our purposes, though, I want to stick with our faithful old TRS-80 for just a little bit more. Next time I’ll be taking a close look at the first commercial RPG to be developed and sold for that platform, The Temple of Apshai (1979). As an heir both to Dungeons and Dragons and the early CRPG tradition that began with pedit5 and dnd, Apshai will give us a chance to see how a CRPG of this very early era actually played.

 
 

Tags: ,

From the Tabletop to the Computer

Let’s say that it’s the mid-1970s, and that you’re an early fan of Dungeons and Dragons, still a tiny offshoot of the niche hobby that is wargaming. Let’s further say that you have regular access to a computer at your place of education or work, and that you know how to program it. It might seem absurd to imagine a substantial overlap between the tiny number of people playing D&D circa 1975 and the decidedly limited if not quite so minuscule number who had access to a computer at that time, but in fact Will Crowther was hardly an anomaly; there was an inordinate number of hackers among early fans of the game. We can assume that hackers’ love of complex systems brought them to the game, just as it drew them to fantasy and science-fiction literature such as the works of Tolkien, where character and plot were subservient to (or at least equal in importance with) world-building.

So, we have a substantial number of hackers entranced with D&D. Hackers being hackers, it’s not difficult to guess what happened next: various projects got under way to bring the experience of D&D to the computer. This was a task for which, depending on how you looked at it and to whom you talked, the computer was either ideally suited for or woefully unequipped to handle. We’ll take the best-case scenario first.

D&D was complicated. Even the original 1974 rules, which virtually everyone agreed were crude and sketchy in many areas, filled three separate booklets of about 35 pages each while recommending that the players also have on hand a copy of Gygax’s earlier Chainmail rules. But that was only the beginning. Just the core of Advanced Dungeons and Dragons, the definitive rules for the hardcore which TSR rolled out over the last three years of the 1970s, ran to hundreds of pages housed in three big, close-typed, hardcover volumes. To this ample base were added layer after layer of further embellishment via yet more hardcover volumes and an endless stream of Dragon magazine articles. It’s fair to say that a certain subset of D&D players — those who took after Gygax himself — absolutely reveled in all of this minutiae. Indeed, for some players the baroqueness of the whole endeavor was the major part of its appeal. Plenty of others, though, were like Arneson, in it for the visceral thrill of lived (if imaginary) experience. When they mustered their last bit of carefully hoarded mana to cast Cone of Cold, their last memorized spell, on the Lizard King (apologies to Jim Morrison), these players did not want to spend ten minutes cross-referencing manuals, calculating probabilities, and pondering such unsolvable existential conundrums as just why the hell an armor class of -5 was vastly better than an armor class of 10. They just wanted to know whether their spell sputtered and died, taking with it their party’s last hope, or whether the Lizard King had been turned into a giant green popsicle. Computers were pretty good at crunching numbers, and happy to apply even the most obtuse of rules to them. What if all of those tedious bits could be stuck into the computer, programmed and tinkered with by the Gygax-types of the world who enjoyed such things, leaving the Arnesons of the world free to just play? As an added bonus, the use of a computer might mean they could play all alone on their own time if they wanted to, rather than needing to assemble four or five friends. It seemed like a dream come true.

But wait a minute, said the naysayers (a group which included, ironically, many of the most committed Arnesons). One of the major things that defined D&D as different from any game that had come before was the sheer scope of possibility it offered to its players. A player was free, theoretically at least, to do absolutely anything she wanted to at any time. It was then up to the DM to find the rule he felt applied best from the small library he had lugged with him to the session. Failing that, he had to use his judgment to make up something appropriate on the spot. (We could note at this point that all of those rules TSR was constantly pumping out could never come to cover every conceivable situation anyway, and that there must come a point of diminishing returns where just making things up in such unusual circumstances was preferable to buying yet more rulebooks in the forlorn hope of covering all the bases, but let’s just let that go.) A computer, of course, can’t make judgment calls; it can only do what it’s been programmed to do. Further, it cannot appreciate the dashing rogue of a leather-clad thief with a severe aversion to wood elves (a case of childhood trauma) you have so creatively personified. It cannot craft an adventure into the heart of the forest just for you, during which Dirk Darkstone will have to confront his horror of effeminate green-clad men wielding bows. It can’t even provide you with Tasha Brightstone, the virtuous blonde paladin in the chainmail bikini torn between her desire for Dirk and the Code of the Virgin Warrior to which she has signed her name. Every computer program ever created, games included, must ultimately offer the user only the limited menu of possible actions anticipated by its designer. Whether that set consists of the up-and-down trackball motions of Pong or the various verbs a text-adventure designer has coded his game to recognize, this constraint is immutable. How then can a computer administer a game whose players can do literally anything? The gospel of tabletop D&D tells us that, even when presented with a tempting dungeon to plunder by the DM, the players are perfectly free to walk on past the Ominous Castle of the Mad Wizard Yordor and spend the evening trying to get a really good brawl started in the local tavern instead. So, the Arnesons of the world tell us, D&D and the computer are not such a marriage made in heaven. The computerized D&D player could avoid the Mad Wizard only by turning off the computer and doing something else, after all.

We’ve certainly hit upon a significant limitation, but let’s think about all this again before we go too much farther with that train of thought. I submit that in practice the players of D&D are restricted in their field of action, by social if not rules-derived constraints. How would you feel if you were that DM who had spent his entire weekend designing the Castle of the Mad Wizard Yordor, stocking it with fearsome monsters (but balanced to not be too much for the players to handle if they play it smart) and devious traps (but not so devious they cannot be disarmed most of the time by a thief of exactly the same level as Dirk Darkstone if he is cautious), only to have your players march on past the lot to go grope the local chicks in the pub? I’m guessing you’d consider the players a bunch of ungrateful bastards whom you’d just as soon not play with again. Thus, there is an implied social contract between DM and players, one in which the players, at least in the broad strokes, are expected to, well, do what is expected of them.

Further, I submit that the rhetoric of D&D as a form of improvisational storytelling and the reality of most player’s experience of the game were somewhat at odds. The AD&D Player’s Handbook tells us:

You interact with your fellow role players, not as Jim and Bob and Mary who work at the office together, but as Falstaff the fighter, Angore the cleric, and Filmar, the mistress of magic! The Dungeon Master will act the parts of “everyone else,” and will present to you a variety of new characters to talk with, drink with, gamble with, adventure with, and often fight with! Each of you will become an artful thespian as time goes by…

The “fight with” part of the extract above was the really important part to most players, the thing that defined the experience of D&D. TSR released at least a hundred adventure modules that had players descending into one thinly justified underground lair or another to kill things and take their stuff using the 23 pages of combat rules found in the Dungeon Master’s Guide alone, and exactly zero that principally involved talking, drinking, or gambling with new friends. Even Gygax seemed of two minds about the real point of D&D. For all the parallels he drew with Shakespeare and Aristotle, in practice he was a dungeon crawler all the way, dismissive of elaborate role-playing: “If I want to do that, I’ll join an amateur theater group.” I submit that D&D was in practice not mostly played by groups of “artful thespians,” but by scruffy teenage boys and men perfectly happy to remain Jim and Bob as they pondered the best way to kill that group of trolls in the next room. And that experience of D&D a computer could, within inevitable limits, simulate pretty well.

 
 

Tags:

Defining the CRPG

There’s a whole lot of Dungeons and Dragons in the original Adventure. Its environs may be based on Kentucky’s Colossal Cave, but the central premise of exploring and looting an underground environment filled with strange dangers and treasure has as much to do with D&D as it does with caving. Even some of the ways in which that environment is presented are strikingly similar. A typical D&D dungeon was, like Adventure‘s, divided into a series of discrete, self-contained rooms. Here’s one of the maps that accompany Temple of the Frog, the first published D&D “adventure module,” which appeared as part of the second D&D supplement, Blackmoor, in 1975:

And here’s the description of a couple of these numbered rooms:

Room 3: Is the headquarters of the traders sent out to sell the junk and is also the office of the chief of accounting. Hidden in this desk are 600 pieces of platinum that he has embezzled. (The High Priest knows about this but does not seem to care.)

Room 4: Is the office of the Commander of the palace guard where he goes to run the security arrangements in the Temple. Within are the master alarms for the palace, so that the exact location of trouble can be registered and personnel sent to counter the intrusion. From here he can communicate, via a desk communicator, with other officers and sergeants under his command. There is always an officer and two sergeants on duty in this room and only the rings worn by the High Priest Commander of the Guard or the Chief Keeper will gain admittance. (No one is aware that the latter has such a privilege, and it has not been used for many years.)

Later D&D adventures made this similarity with the IF room even more obvious by including a boxed text with every room that the DM should read to the players upon their first entering, just like the ubiquitous IF room description. At least under all but a very skilled DM, the rooms of a D&D dungeon tended to feel oddly separate from one another, each its own little self-contained universe just like in a text adventure; many was the party that fought a pitched battle with a group of monsters, then, upon finally vanquishing them, stumbled upon some more still slumbering peacefully in the next room just as the room description said they should be, undisturbed by the carnage that just took place next door. Speaking of combat, the heart of most D&D adventures, Adventure even had a modicum of that as well, in the form of the annoying little dwarfs that harried the player until they were all dispatched.

For all these similarities and for all the acknowledged influence that his experiences as a D&D player had on Crowther’s original work, though, virtually no one refers to Adventure or its many antecedents as computer RPGs. What gives? One thing we might take note of is that Crowther made no real attempt to translate the actual D&D rules into his computer game. He took inspiration from some of its themes and ideas, but then went his own way, whereas the mechanical debt that the family of games I now want to begin to cover owed to D&D was as important as the thematic debt. Just leaving it at that seems a bit unsatisfying, though. Maybe we can do a little bit better, and in the process come up with something that might be useful in a broader context.

Matt Barton says something really interesting in the first chapter of Dungeons and Desktops: The History of Computer Role-Playing Games:

To paint with a broad brush, we could say that the adventure gamer prioritizes deductive and qualitative thinking, whereas the CRPG fan values more inductive and quantitative reason. The adventure gamer works with definitions and syllogisms; the CRPG fan reckons with formulas and statistics. The only way for a character in a CRPG to advance is by careful inductive reasoning: if a certain strategy results in victory in six out of ten battles, it is better than another strategy that yields only three out of ten victories. This type of inductive reasoning is rare in adventure games but is plentiful in CRPGs, where almost every item has some statistical value (e.g., a longsword may do ten percent less damage than a two-handed sword, but allows the use of a shield).

These differences in thinking arise of course from very different approaches to game design and narrative on the part of the works’ creators. The typical adventure-game designer spends most of her time crafting a pre-defined experience for the player, building in a series of generally single-solution set-piece puzzles and a single (or, at most, modestly branching) narrative arc. The CRPG designer, meanwhile, pays less attention to such particulars in favor of crafting an intricate system of rules and interactions, from which the experience of play, even much of the narrative, will emerge. CRPGs, in other words, are essentially simulation games, albeit what is being simulated is an entirely fictional world.

At first blush, there perhaps doesn’t seem to be any room for debate about which approach is “better.” After all, if given a choice between jumping through hoops to progress down a single rigid path or crafting one’s own experience, writing one’s own story in the course of play, who would choose the former? In actuality, though, things aren’t so clear-cut. There are inevitable limits to any attempt to create lived experience through a computer simulation. It’s perfectly feasible to simulate a group of adventurers descending into a dungeon and engaging in combat with the monsters they find there; it’s not so easy to simulate, say, the interpersonal dynamics of a single unexceptional family. People have tried and continue to try, but so far the simulational approach to ludic narrative has dramatically limited the kinds of stories that can be interactively lived. Thus, the simulational approach can paradoxically be as straitening as it is freeing. And there’s another thing to consider. The more we foreground the simulational, the more we emphasize player freedom as our overriding goal, the further we move from the old ideal of the artist who shares his vision with the world. What we create instead may certainly be interesting, even fascinating, but whatever it ends up being it becomes more and more difficult for me to think of it as art. Which is not to say that every game design should or must aspire to be art, of course; given my general experience with games that explicitly make claims to that status, in fact, I’d just as soon have game designers just concentrate on their craft and let the rest of us make such judgments for ourselves.

I must be sure to point out here that “emergence” and “set-piece design” do not form distinct categories of games, but rather the opposite poles of a continuum. Virtually every game has elements of both; consider the scripted dialog that appears onscreen just before the player kills the Big Foozle in a classic CRPG, or the item that a player must have in her inventory to solve the otherwise set-piece text-adventure puzzle. It’s also true that disparate games even within the same genre place their emphasis differently, and that over time trends have pulled entire genres in one direction or another. Here’s a little diagram I put together showing some of what I mean:

As the diagram shows, modern big-budget RPGs such as those from Bioware have actually tended to include much more set-piece story than their classic predecessors, in spite of the vastly more computing power they have to devote to pure simulation. (There’s some great material in Noah Wardrip-Fruin’s Expressive Processing about the odd dichotomy between the amazingly sophisticated simulational part of a game like Knights of the Old Republic and the limited multiple-choice conversation system the player is forced into whenever emphasis shifts from the hard mechanics of exploration and combat to the soft vagaries of story and interpersonal relationships.) Modern IF has also trended away from simulation, de-emphasizing the problems of geography, light sources, inventory management, sometimes even combat of old-school text adventures to deliver a more author-crafted, “literary” experience.

But I wanted to define the CRPG, didn’t I? Okay, here goes:

A computer role-playing game (CRPG) is an approach to ludic narrative that emphasizes computational simulation of the storyworld over set-piece, “canned” design and narrative elements. The CRPG generally offers the player a much wider field of choice than other approaches, albeit often at the cost of narrative depth and the scope of narrative possibility it affords to the designer.

At least for now, I think I’m going to leave it at that. Most other definitions tend to emphasize character-building and leveling elements as a prerequisite, but, while I certainly acknowledge their presence in the vast majority of CRPGs, it seems limiting to the form’s possibilities to make that a requirement. Of course, I could have also simply used the definition we used in the 1980s: in adventure games you explore and solve puzzles, in CRPGs you explore and kill monsters. But that’s just too easy, isn’t it?

So, we hopefully now have some idea of what it really is that separates a CRPG from the works of Crowther and Woods and Adams. With that in place, we can begin to look at the first examples of the form next time.

 
 

Tags: ,