Game Design: Theory & Practice- P8 pps

How did you come to work on Zork Zero? It was my idea to do a prequel to the game, and everyone loved the idea of call - ing such a prequel Zork Zero. It poked fun at the whole sequelitis syndrome that gripped and continues to grip the computer game industry. I had written Sorcerer, the second game of the Enchanter trilogy that can be unofficially considered to be Zork V. It was in the same universe as Zork, and as part of writing the game I com - piled the first compendium of Zork history, dates, places, characters, et cetera, by combing through the Zork games and the first Enchanter game, and then attempting to tie them all together with a comprehensive geography and history. There was some initial resistance to this from the original authors, but it quickly became appar - ent how necessary—and later, how popular—a step it was. So, I was pretty versed in the Zork milieu when Zork Zero began to be dis - cussed. In fact, I think it’s safe to say that I was more of an expert on Zork-related details than the original authors. Zork Zero had been on my list of potential next projects for a couple of years, and probably would have been my game the year that I did the Planetfall sequel, Stationfall, except that Brian Moriarty had just finished an adventure-RPG hybrid that we had decided to place in the Zork universe called Beyond Zork, and two Zork games in such close proximity wouldn’t work. As an aside, after finishing Stationfall, the decision was between Zork Zero and an idea that I had been tinkering with for years: an adventure game set on the Titanic during its maiden voyage. But Infocom’s management finally decided, and I heard this many times over the next few years as I pitched this project to many pub- lishers during my post-Infocom days, “people aren’t interested in the Titanic.” So when the Cameron movie came out and became the most popular movie ever, it was something of a bittersweet moment for me. When the decision came down to go ahead with Zork Zero, the first thing I did was convene a brainstorming session with the original “implementors,” or three out of four, at any rate. Marc Blank (who had long since left Infocom and moved to the west coast), Dave Lebling (still a game author at Infocom), and Tim Anderson (still a “senior scientist” special-projects programmer at Infocom) were all there. The fourth original author, Bruce Daniels, had long since moved on. The only thing set in stone going into this session was that the game would be a prequel, and that it would end “West of a white house.” This session produced the very general frame - work for the game: the setting of Dimwit’s castle, the reasons for the destruction of the Flathead dynasty, and the collection of artifacts belonging to each of the twelve Flatheads. Zork Zero is a strange hybrid of a game: it’s almost all text, with just some snip - pets of graphics thrown in. What was the general idea behind the design? At the time, Infocom was undergoing some stress and soul-searching. Our sales had been dropping for several years. Going into the 1987 product cycle, the thinking 188 Chapter 10: Interview: Steve Meretzky TEAMFLY Team-Fly ® from Infocom/Activision management was “There are N thousand hard-core adven - ture game fans who’ll buy any Infocom game no matter how many we put out. Therefore, the strategy should be to put out as many games as possible.” We put out eight games during 1987, whereas in any previous year we’d never put out more than five. And all of them did pretty badly. So, going into the 1988 product cycle, the thinking was “Text adventures are a dying breed; we need to add graphics to our games.” Throughout Infocom’s existence, we had always denigrated graphical adven - tures, and during the early and mid-’80s, this was pretty correct. While the early micros were pretty good at arcade-game-style graphics, they were pretty awful at drawing pictures, as seen in the graphic adventures of that time period. But then the Macintosh came out, providing much better black and white graphics than had been seen to date, followed by the Amiga, which did much better color graphics than anyone had seen before. IBM-PC graphics cards were also getting better. So graph- ics were starting to look reasonable and give all-text a run for its money. Infocom was a bit slow to come around to this truth. So, in late ’87 and early ’88, Infocom’s development system was being com- pletely overhauled to handle the addition of graphics. At the same time, the game authors were collectively and individually wrestling with the issue of how to use graphics in games. Some people decided just to use them to illustrate occasional scenes, the way a book with occasional illustrations might use pictures. This is what Dave Lebling did with his IF version of Shogun. Since the goal for Zork Zero was to be a classic puzzle-based adventure game on steroids, I decided that I primarily wanted to use graphics for puzzle-based situa - tions, so I created five graphical puzzles: a rebus, a tower of Hanoi, a peg-jumping game, a pebble-counting game called nim, and a card game called double fanucci. But I didn’t want the game to just look like an old-fashioned text adventure the rest of the time, so I designed the three different decorative borders: one for outside, one for inside buildings, and one for inside dungeons. I also gave every room an icon, and then used those icons for the on-screen graphical maps, which was a pretty good mnemonic device. Finally, I used graphic illustrations in the Encyclopedia Frobozzica, a book in the library that was basically an in-game version of the Zork universe compendium that I’d begun compiling while working on Sorcerer. But none of the graphics games sold any better than the previous year’s all-text games, and by mid-’89 Activision decided to shut Infocom down. They didn’t improve sales at all? I would say that during the previous year, ’87, all the games sold around twenty thousand. And the four graphical games that came out in late ’88 and early ’89 also sold around those same numbers. Chapter 10: Interview: Steve Meretzky 189 So why do you think that was? LucasArts and Sierra seem to have been quite suc - cessful with their graphical adventures around that time. Yes, at the time Sierra was selling several hundred thousand copies of their games. But certainly not Lucas nearly as much. Lucas was in fact quite frustrated that they were putting out games that they felt were technically pretty identical to the Sierra games and in terms of writing and content were really superior to them, and yet only selling a fifth or a third as many copies. And I don’t really know what to think about that. It might just be that Sierra was doing a really good job produc - ing games that were very well aimed at a middle-brow audience, at kind of the broadest audience. And much like many of the Infocom games, Lucas games tended to appeal to a somewhat more sophisticated and therefore smaller audience. So that’s why you think the Infocom graphical games didn’t take off? Well, no. I think it was much more that by that point the graphical games had become pretty sophisticated in terms of being not just graphical adventures but ani- mated graphical adventures, like the Sierra and Lucas games of that period. And the Infocom games weren’t really more than illustrated text adventures. Even though the graphics were introduced, I don’t think it was perceived as being that much of a new animal from what Infocom had been producing up until that point. So do you think Infocom might have been more successful using graphics if they had made them more integral to the design of the games? It’s hard to say what might have happened in ’87 if Infocom had said, “We’re going to go out and exactly imitate the Sierra adventure game engine the way Lucas did.” On the one hand, it has always seemed to me that whoever gets to a market first kind of owns it. And I think that’s another reason that Sierra really dominated Lucas at that point. There were certainly a lot of companies that came in, did text adventures, put a lot of effort into it and did some pretty good text adventures. For example, Synapse Software, in the mid-’80s, with their BTZ engine did a few pretty good games. But they got virtually no sales. It’s just pretty hard to go head to head with a market leader, even with games that are just as good, because it’s hard to make up for that head start. On the other hand, Infocom certainly had a name that was pretty synonymous with adventure games, so if there was anyone who could have made headway against Sierra’s head start it probably would have been Infocom. But at this point it’s completely academic, obviously. The Infocom games all ran off of pretty much the same storytelling system, using nearly identical game mechanics from game to game. Do you think this shared technology and design worked well? It worked extremely well for its time. It allowed us to get our entire line of games up and running on a new computer within weeks of its release. This was a 190 Chapter 10: Interview: Steve Meretzky tremendous commercial edge during a time when the market was fragmented between many different platforms and new, incompatible platforms were coming out all the time. For example, there was a time when there were about twenty-five games available for the original Macintosh, and fifteen of them were Infocom games. This annoyed the Mac people at Apple to no end, since we didn’t use the Mac GUI. Also, the type of games we were doing lent themselves well to a “line look,” both in the packaging and in the games themselves. It gave them a literary feel: Infocom games all look similar in the same way that all books look similar. But even today, engines are usually used for several games, particularly if you include expansion packs. And even though the final products appeared to be pretty similar, the Infocom library actually represents several generations of the ZIL engine. There was a pretty major revamping when the “Interactive Fiction Plus” line came along, starting with AMFV, and then another pretty major revamping around ’87 with the introduction of an entirely new, much more powerful parser. And then, of course, there was a major overhaul for the introduction of graphics in ’88. A lot of effort was put into the Infocom parser, and it was well respected as the best in the industry. Did it ever get so good that you thought it couldn’t get any better? Certainly, by the time of the new from-the-ground-up parser circa 1987, I thought we had a parser that, while it could certainly be improved, was about as good as we’d ever need for a gaming environment. After all, we weren’t trying to understand all natural language, just present-tense imperative sentences. The only area where I would have liked to see continued improvement was in the area of talk - ing to NPCs. But the main problem with making NPCs seem more deep and real wasn’t due to parser limitations, it was just the sheer amount of work needed to give a character enough different responses to keep that character from seeming “canned,” even for a short while. I personally loved and still love the text-based interface, both from a player and a game writer point of view. But I don’t mind either reading or typing, and some people dislike one or the other or both, and that tended to limit our audience, espe - cially as non-reading, non-typing alternatives proliferated. But I find the parser-based input interface to be by far the most powerful and flexible, allowing the user to at least try anything he/she can think of, and allowing the game writer to develop all sorts of puzzles that wouldn’t be possible with a point-and-click inter - face. So many point-and-click adventure games became a matter of simply clicking every object in sight in every possible combination, instead of thinking through the puzzle. Chapter 10: Interview: Steve Meretzky 191 What do you say to criticisms that the parser interface often proved more frus - trating than intuitive, and that though the player may know what they want to do, he or she may have trouble finding the correct words for that action? I think that’s simply a poor parser. I can remember playing one Sierra game where there was what I thought was a horse on the screen, and I was trying to do all sorts of things with the horse, and it later turned out it was a unicorn. In those days, when the resolution was so grainy, I was simply not noticing the one pixel that indi - cated a horn. And so when I was saying stuff like, “Get on the horse,” it wasn’t saying, “There’s no horse here,” which would have tipped me off that maybe it was a unicorn. Instead it was responding with, “You can’t do that” or something much less helpful. So to me, the fault wasn’t that the game had a parser interface; the fault was that the game was not well written to begin with or well tested. Certainly when someone sits down with even the most polished Infocom game, there tends to be, depending on the person, a one-minute or a half-hour period where they’re kind of flailing and trying to get the hang of the syntax. But for most people, once they get past that initial kind of confusion, a well-written parser game isn’t particularly frustrating. Even in the later Infocom games, we were starting to introduce some things that were really aimed at making that very initial experience less difficult: trying to notice the sorts of things that players did while they were in that mode, and make suggestions to push them in the right direction. The game would try to catch if they typed in an improper kind of a sentence, such as asking a question or using a non-imperative voice. It would try to notice if they did that two or three times in a row and then just say, “The way to talk to the game is,” and then give a few examples. And I think that the really critical thing about the parser interface has nothing to do with typing, it is being able to use natural language for your inputs. Did you ever feel limited by the Infocom development system? The system was extremely powerful and flexible, and could grow to meet the need of a particular game fairly easily. A minor exception was any change that required a change to the “interpreter.” Every game sold consisted of the game com - ponent, which was machine independent, and an interpreter, which was a machine-specific program which allowed the game component to run on that partic - ular microcomputer. Since there were twenty or more interpreters (one for the Apple II, one for the Mac, one for the DEC Rainbow, one for the NEC PC-800, et cetera) a change to the interpreter required not changing just one program, but changing twenty-plus programs. So that could only be done rarely or when it was extremely important, such as changing the status line in Deadline to display time instead of score and moves. A more stringent limit was imposed by the desire to run on the widest possible array of machines, so we were always limited by the capabilities of the smallest and 192 Chapter 10: Interview: Steve Meretzky weakest of those machines. In the earliest days, the limiting machine was the TRS-80 Model 1, whose disk drive capacity limited the first games to an executable size of 78K. As older machines “dropped off” the to-be-supported list, this limit slowly rose, but even when I wrote HHGTTG, games were still limited to around 110K. Generally, this limit would be reached midway through testing, and then every addition to the game, to fix a bug or to handle a reasonable input by a tester, would require ever more painful searches for some text, any text, to cut or con - dense. At times, this was a good discipline, to write lean, to-the-point text. But often it became horrible and made us feel like we were butchering our own children. Okay, that’s a slight exaggeration. How did the development process work at Infocom? Were you fairly free to choose what games you made? In the early days, things were pretty informal, and decisions were made by fairly informal consensus. In the later days, particular after the acquisition by Activision, decisions were much more mandated by upper management. Generally, the choice of a game was left up to the individual author. Authors with more of a track record, like Dave Lebling and myself, had more leeway than a greenhorn implementor. Of course, there were marketing considerations as well, such as the strong desire to complete trilogies or the opportunities to work with a licensed prop- erty such as HHGTTG. One thing that was standard over the whole seven-plus years that I was at Infocom was the “Implementors’ Lunches,” or, for short, “Imp Lunches.” These were weekly lunches at which the game writers would get together to talk about the games in development, share ideas, critique each other’s work, et cetera. It was probably the most fun couple of hours of the week. There wasn’t too much oversight during the first few months of a game’s life, while the implementor was working pretty much alone, other than at the Imp Lunches, any impromptu brainstorming, or requests for help/advice. But once the game went into testing, first among the other writers, then with the internal testing group, and then finally with outside “beta testers,” the game was under the micro - scope for months on end. During this time, bugs and suggestions would often run into the thousands. How fluid and changing was the design of an Infocom game? This varied from implementor to implementor. My own style was to do a little bit of on-paper design before starting, mostly in creating the geography and any “background universe” documents such as a time line in the case of Sorcerer,orthe rules of the deserted planet’s language in Planetfall. But for the most part I would just jump right in and start coding with most of the characters and puzzles living only in my head. Chapter 10: Interview: Steve Meretzky 193 The Infocom development system was terrific, compared to the graphic-based systems I’ve worked with since those days, because just the game writer working alone could implement an entire section of the game in only a couple of days, and then try it out and see how it worked. If it had to be scrapped because it wasn’t working, it was no big waste of time or resources. This allowed for a lot of going back and rewriting big sections of the game, which is inconceivable nowadays, where such a decision might mean throwing away a hundred thousand dollars worth of graphics. Was there a lot of playtesting on Infocom titles? Lots of testing. Since the development system was quite stable during most of Infocom’s life, the testing was able to concentrate on game-specific bugs and game content. There would ideally be about two weeks of “pre-alpha” testing where the other game writers would play a game, followed by two to three months of alpha testing with our in-house testers, followed by a month of beta testing with a couple of dozen outside volunteers. If time allowed, there was also a month of “gamma” testing, which was just like beta testing except that the idea was not to change a thing unless a really major problem was found. Testing for both game-specific bugs and game content went on pretty much concurrently, although more heavily weighted toward content during the early days of testing, and more toward bugs in the later days, when it became increasingly less desirable to make any significant changes to game content. The early testing period was probably the most fun and exciting time in the game’s development. For one thing, after months and months of working alone, not having any idea if a game was any good other than my own instincts, all of a sudden a bunch of people are playing the game, usually enjoying it, and giving tons of feed - back. It’s a real rush. Also, we had an auto-scripting feature where our network would automatically make a transcript of each player’s sessions, which I could read to see what everyone was trying at every point, so I’d often find things which were wrong, but which testers didn’t necessarily realize were wrong. Or I’d find things that they’d tried which were reasonable attempts to solve the puzzle at hand and I’d try to reward such an attempt with a clever response or with a hint, rather than just a default message like, “You can’t put a tablecloth on that.” It was during the testing period that games became great. Going into the testing period, the game was more like a skeleton, and the testing period, as one of our test - ers once said, “put meat on the bones.” Lots of the humor, the responses to wacky inputs, the subtle degrees of difficulty, the elimination of unfair puzzles—these were all the products of Infocom’s excellent testing group. 194 Chapter 10: Interview: Steve Meretzky The packaging for Infocom games was really unique. Why did the company go above and beyond what so many other game publishers did? When Infocom started, the standard for computer game packaging was some - thing similar to a Ziploc bag. It was just a clear plastic bag with a Ziploc top and a hole to hang on a pegboard in stores; the bag would hold a floppy disk and an often cheaply photocopied manual. In fact, the early Radio Shack versions of Zork were in just such a package. The original publisher of Zork I was a company in California called Personal Software. In fact, the product manager for the Zork line at Personal Software was Mitch Kapor, who went on to found Lotus. Shortly after they starting publishing Zork, Personal Software hit it big-time with a program called Visicalc, the first suc - cessful piece of business software for computers. They changed their name from Personal Software to Visicorp, and decided that they didn’t want to waste their time dealing with games, and they gave Zork back to Infocom. Rather than find a new publisher, Infocom decided to be its own publisher, and hired an agency to design the packages. The result was the “blister pack” packages for Zork I and Zork II, the first time such packages had been used for computer games. This is the type of package in which a clear piece of molded plastic is glued to a cardboard back, with the contents visible through the clear plastic, in this case the contents being the Zork manual with the disk out of sight behind it. When it was time for the packaging design on Infocom’s third game, Deadline, Marc Blank went to the agency with a series of out-of-print books from the 1930s, written by Dennis Wheatley. With names like Murder Off Miami and Who Killed Robert Prentiss?, the books were a portfolio of reports and clues, just like a police detective would be given when investigating a case: interviews with witnesses, typed letters, handwritten notes, railway tickets, newspaper clippings, a used match - stick, and lots more. The idea was that you were the detective, and after sifting through the evidence, you should decide who the murderer was and how they did it, and then open a sealed section of the book and see if you were right. Marc was very influenced by those books in creating Deadline—in fact the original working title was Who Killed Marshall Robner?—and he wanted the agency to be very influenced by them in creating the packaging for Deadline. Marc wanted the player to feel like they were a detective being placed on a case from the moment they opened the package. Also, because of the strict limits on game size, having lab reports and suspect interviews in the package freed up space in the game for more interactive content. The Deadline package that resulted is very reminiscent of those Dennis Wheatley books, with a photo of the crime scene, inter - views, fingerprints, lab analyses of things like the teacup found near the body, and even a bag of pills labeled “Pills found near the body.” Those were actually white-colored SweeTARTS. Chapter 10: Interview: Steve Meretzky 195 The Deadline package was a huge hit, even though we charged $10 more for it, $50 MSRP instead of $40 MSRP. We decided that great packaging was fun, was a great value-added, was a great way to “raise the bar” and make it harder for new competitors to enter our market space, and most importantly, it was a way to dis - courage pirating of our games. It was more difficult and less cost effective to need to copy a bunch of package elements as well as the floppy disk. Also, because the packages were so neat and so integral to the experience of playing the game, many people wouldn’t have felt they owned the game unless they owned the complete original packaging. The next games were Zork III and Starcross. Zork III just went in a blister pack to match its brethren, but Starcross was placed in a large plastic flying saucer, along with an asteroid map of your ship’s vicinity. This package, while problematic for some stores because of its size and shape, was phenomenally eye-catching and pop - ular. Recently, a still-shrink-wrapped copy of Starcross in this original packaging sold for three thousand dollars on eBay. My favorite package of all the ones that I worked on was LGOP, with its scratch ’n’ sniff card and 3D comic. The comic was a collaboration between me, a comic book artist, and a guy who specialized in translating conventional 2D comic draw- ings into 3D layers. For the scratch ’n’ sniff card, I got several dozen samples from the company that made the scents. Each was on its own card with the name of the scent. So one by one I had other Infocom employees come in, and I’d blindfold them and let them scratch each scent and try to identify it. That way, I was able to choose the seven most recognizable scents for the package. It was a lot of fun see- ing what thoughts the various scents triggered in people, such as the person who was sniffing the mothballs card and got a silly grin on his face and said, “My grand - mother’s attic!” We, the implementors, had pretty wide latitude on the choice of package ele - ments, as long as we stayed within budgetary parameters. But marketing often had good ideas too, suggesting that my idea for a book in Zork Zero become a calendar, and suggesting things like the creepy rubber bug in the Lurking Horror package. But most of the best ideas came from the writers. The best package pieces were those that were designed in from the beginning of the game, rather than tacked on as an afterthought once the packaging process started in mid-alpha. Most other game companies had anti-piracy copy protection in their packages, but it was often completely obvious and mood-destroying, such as “Type the seventh word on page 91 of the manual.” With the better Infocom pack - age elements, you never even realized that you were involved in an anti-piracy activity, because the package elements were so seamlessly intertwined with the gameplay. And, of course, in the all-text environments of our games, the package elements were a great way to add visual pizzazz to the game-playing experience. 196 Chapter 10: Interview: Steve Meretzky There seems to have been a clear difference between Infocom games and the games the rest of the industry offered, especially in terms of a consistent level of quality. Why do you think this was? How was this quality maintained? Partly, it was the very early philosophy of Infocom, and even before Infocom, in the creation of Zork, which was to take a fun game, Adventure, but do it better. So there was always a strong desire to be the best. Also, partly it was because the peo - ple who made up Infocom were just a really smart and talented group of people. And partly it was luck. We had early success, so when we created each new game we could invest a lot of time and money into it, knowing that its sales would justify the investment, while many other companies couldn’t assume that level of sales and therefore couldn’t afford the same level of investment. Our always improving development environment, parser, et cetera, was a big reason for the high level of quality. The talented testing group, and the time we scheduled for testing, bug-fixing, and general improvement, was another big factor. Did Infocom’s consistent quality level allow it to weather the “crash” of the mid-’80s pretty easily? The mid-’80s crash began with a crash on the video games side, and then spilled over into the PC market. Many companies had a mixture of video game and microcomputer SKUs, but Infocom was entirely in the PC market. Also, our games were as un-video-game-like as possible. Another reason why the mid-’80s slump had little effect on Infocom’s game sales was that we were on so many machines, and we could quickly get onto any new computers that were released. For example, the Mac came out in early 1985, and our games were extremely successful on the early Macs. And, of course, the high quality helped, because during any slump it’s always the schlocky products that die first. To me, it seems that Infocom games are the only titles from the early ’80s that don’t seem at all dated. Why do you think that is? Well, graphics from games in the early ’80s look awful, but text just looks like text. So time is kinder to text adventures. And, as we’ve already covered, the games were of a very high quality, which helps them hold up over time. And, once you’ve eliminated technical obsolescence as an issue, ten to twenty years isn’t a very long time for a creative work to age well or not well. Think about books, movies, TV shows, et cetera from the same period. Only a very few that were unusually topical would seem dated today, and Infocom games certainly weren’t topical, with perhaps AMFV as a lone exception. And it’s certainly not unusual for people to continue to enjoy the best works long after their creation: I Love Lucy is forty years old, Gone With the Wind is sixty years old, the films of Charlie Chaplin and Buster Keaton are eighty years old, Alice in Wonderland is one hundred fifty years old, and Shake - speare’s plays are four hundred years old. Chapter 10: Interview: Steve Meretzky 197 [...]... It’s just one of the most expensive types of games to make, and the top N adventure games sell less than the top N games in almost any other category Of course, it can be argued that the adventure game isn’t dead, but has simply evolved into action/adventure games, e.g., Tomb Raider, and platform games, e.g., Mario, Crash Personally, I don’t consider any game that relies on even a relatively small degree... and San Francisco Rush, where the only story found is in the game s setting But other games, such as Marathon, Command & Conquer, and Thief, have taken a story and made it work as a key part of the gameplay, creating tales so rich that players find themselves sucked into the game- world more than if the games had been story-less And still other games, such as A Mind Forever Voyaging, Myst, and the Ultima... issue? Yes, that became increasingly a big issue as my games were competing not so much against other adventures and RPGs, but against strategy games like Civilization and RTS games like WarCraft To some extent, you can have replayability in adventure games For example, Suspended was an extremely replayable Infocom game, as you strove to finish the game with the lowest possible casualty levels Even with... How organic is the design process for your games? Did the onset of graphics end up limiting how much you could change your game? Very organic, but you’re right, graphics games are far more limiting in terms of how much the game can change once it gets beyond the original design stage Of all my games, AMFV was probably the one that changed the most as the game s production progressed Originally, it... adventure game of the year It was a wonderful game I didn’t think from a puzzle point of view it was that great, but from an art direction point of view it was probably the best adventure game I’d ever seen It seems strange that adventure games used to be among the best-selling games, and now they don’t sell well at all Maybe my numbers are off No, that’s really true Around the time of the King’s Quest games... allows me, in a game like LGOP or Hoboken, to find and then hone a voice/style while a lot of the game is still on the drawing board, resulting in better, more unified work AM FL Y A big issue for adventure games seems to have been difficulty For instance, if the game is too hard, you are likely to frighten away new players But if the game is too easy, the hard-core players will dismiss your game Do you... fun Of course, the funnest parts of making games are more fun than the funnest parts of playing games So much writing in games is dreadful What do you think is important to keep in mind when writing for a game? All types of writing are different, and there are plenty of excellent novel writers who couldn’t write a screenplay or vice versa And writing for games is at least as different as those two... point that they’re worth putting in adventure games, there will be a growing emphasis on story over puzzles, games and game- worlds will get larger, there will be more realistic, believable characters in adventure games, many people who have been successful storytellers in other media, such as fiction writers and movie auteurs, will gravitate toward adventure games as the storytelling medium of the future... anything that Superhero League of Hoboken wasn’t a straight adventure game and were therefore nervous, so the only way I could convince them was to make it an RPG/adventure game hybrid It’s the only superhero game I am aware of that was not dreadful Why do you think so few superhero games have been done? I think that the dearth of superhero games is mostly a legal/licensing issue Most companies probably... Our games got consistently easier, which didn’t seem to help attract any new players, and definitely seemed to turn off our hard-core fans Hint books and later in -game hints were definitely considered ways to keep the games pretty hard without discouraging newer, less sophisticated, less masochistic players It’s a pretty good solution, because if the game is too hard, hints can help, make the game . hard-core adven - ture game fans who’ll buy any Infocom game no matter how many we put out. Therefore, the strategy should be to put out as many games as possible.” We put out eight games during 1987,. identical game mechanics from game to game. Do you think this shared technology and design worked well? It worked extremely well for its time. It allowed us to get our entire line of games up. was able to concentrate on game- specific bugs and game content. There would ideally be about two weeks of “pre-alpha” testing where the other game writers would play a game, followed by two to