# Game Design: Theory & Practice- P8

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:30

0
44
lượt xem
4

## Game Design: Theory & Practice- P8

Mô tả tài liệu

Game Design: Theory & Practice- P8: My earliest recollection of playing a computer game was when I stumbled upon a half-height Space Invaders at a tiny Mexican restaurant in my hometown. I was perhaps six, and Space Invaders was certainly the most marvelous thing I had ever seen, at least next to LegoLand.

Chủ đề:

Bình luận(0)

Lưu

## Nội dung Text: Game Design: Theory & Practice- P8

4. Chapter 10: Interview: Steve Meretzky 191 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.
5. 192 Chapter 10: Interview: Steve Meretzky 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
6. Chapter 10: Interview: Steve Meretzky 193 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, or the 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.
7. 194 Chapter 10: Interview: Steve Meretzky 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.
8. Chapter 10: Interview: Steve Meretzky 195 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.
9. 196 Chapter 10: Interview: Steve Meretzky 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.
10. Chapter 10: Interview: Steve Meretzky 197 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.