XYZZYnews January/February 1995 Issue #1 +++++++++++++++++++++++++++++++++++++++++++++ HOLLOW VOICE +++++++++++++++++++++++++++++++++++++++++++++ You pick up the magazine. As you flip through its pages, an editorial catches your eye. >EXAMINE EDITORIAL Hello! And welcome to the premier issue of XYZZYnews: The Magazine for Interactive Fiction Enthusiasts. With this 'zine, I hope to create an open forum for fellow gamers who are crazy about computer adventure games, especially text-based adventures. This includes nostalgic fans of the old Infocom games, people who're always on the lookout for new games to play, and designers of new adventure games. XYZZYnews is for anyone who favors computer games that compel players to face intellectual challenges or a series of logic puzzles in order to complete a storyline. Longtime IF fans will recognize the reference to "xyzzy" as the magic word in the original "Advent" or "Adventure" that transports the player from anywhere in the game to a central location. Continuing the "Adventure" theme, you'll notice that the title of this editorial column is "Hollow Voice". If you type "xyzzy" in many text adventures (presumably to see if that strategy will work here too), a "hollow voice" derides your efforts. In contrast, this Hollow Voice won't laugh at anyone's attempts; I hope only that my 'zine and I can be resources for exploring all avenues of adventure gameplay. In the pages of this issue you'll find plenty of game reviews; an interview with Graham Nelson, game designer extraordinaire and developer of the Inform language; a sneak preview of some upcoming text adventures; a how-to piece for game writers on avoiding 10 common design mistakes; the first installment of the Spoiler Column, featuring hints or answers to questions that've come into our e-mailbox; and a step-by-step look at how one game designer solved a sticky bug in his code. I hope that this first issue proves entertaining, informative, and interesting to you. And naturally, I'm looking for your feedback, more game reviews, articles, walkthroughs, Q&A, and other ideas for the second issue. Please write or email me with any feedback or suggestions you may have. Happy gaming! Eileen Mullin xyzzynews@aol.com +++++++++++++++++++++++++++++++++++++++++++++ TABLE OF CONTENTS +++++++++++++++++++++++++++++++++++++++++++++ Contents: Sneak Previews.....2 Interview: Graham Nelson.....3 News Briefs.....8 10 Steps to Great Game Design.....9 Game Reviews Busted.....16 CosmoServe.....17 Curses.....18 Veritas.....19 Odieus.....20 Tales from the Code Front: 5,000 Mailboxes in TADS.....21 Spoiler Column.....23 What's on the Disk.....24 +++++++++++++++++++++++++++++++++++++++++++++ LEGALESE +++++++++++++++++++++++++++++++++++++++++++++ XYZZYnews is published bimonthly by Bran Muffin Communications, 320 West 84th Street, Ste. 5B, New York, NY 10024, USA. Email: xyzzynews@aol.com. Send all inquiries, letters, and submissions to the address above. Contents (c) 1995 XYZZYnews. All rights reserved. Published in the United States of America. Electronic versions: There are currently two versions of XYZZYnews made available online. One is in ASCII and can be viewed with any text reader. You can also download a .PDF file that mirrors the layout of the print version. Use the Adobe Acrobat Reader (available for Windows, Mac, DOS and UNIX) to view the .PDF file; no special fonts or linked graphics are needed. You can obtain Acrobat Reader at ftp.adobe.com or http://www.adobe.com. Subscriptions: Both electronic versions are available at no cost. You can obtain either one by FTPing to ftp.gmd.de. To be added to the mailing list, please write to xyzzynews@aol.com and specify text-only or .PDF version. The print version includes a 3.5" Mac or PC disk and is $21 (U.S.) for one year (6 issues) or $3.50 for a sample issue. For print subscriptions outside the U.S. or Canada, please email or write for rates. All products, names, and services are trademarks or registered trademarks of their respective companies. Editorial deadline for Issue #2 is February 28, 1995. Editor: Eileen Mullin Contributors to this issue: Stuart Beach Neil deMause C.E. Forman Melissa Katz Lauren Meckler Conrad Wong +++++++++++++++++++++++++++++++++++++++++++++ SNEAK PREVIEW +++++++++++++++++++++++++++++++++++++++++++++ This issue, "Sneak Previews" looks at three TADS games that are all set in academic environments. Since all are still in development, their release date information may change. The Legend Lives! by David Baggett, distributed by Adventions, is the highly-anticipated next installment in the Unnkulian series. As a graduate student at Akmi Yooniversity, you've stumbled across a terrible discovery while researching your thesis - the code to an Unnkulian-created virus that's been set loose on the intergalactic AkNet computer network. You need to get to the bottom of several mysteries: figuring out how to stop the virus, determining if the Akmi company has once again joined the Unnkulians' dark forces, and finding out where the Unnkulians have been hiding and what they've been doing in recent years. "The Legend Lives!" has a novel method for changing locations; you must enter a matter mover to transport from one place to another, and you must dial the address combination for your desired destination (and have permission to transport if it's a private address) before you can go anywhere; there's little aimless wandering in this game. As in earlier Unnkulian games, you'll find plenty of cheezy product placements for Akmi goods. Online hints are also available. Look for "The Legend Lives" to release sometime this spring. "MacWesleyan: An Everyday Nightmare" (Mac version; the PC version is called "PC University") by Neil deMause is a surreal exercise in academic bureaucracy. Your goal is to obtain all the necessary signatures on your Student Identification Form and return it to the Registrar's office. This includes getting signatures from your faculty advisor, department chair, dean, the university president, and the U.S. president, not to mention getting your own signature (harder than it sounds). Based at Wesleyan University in Middletown, CT, the game also features speeding Domino's pizza trucks that hinder your safe passage, unusual psychology experiments, and a bus labeled "House of God" that indeed houses the Famous One. "MacWesleyan" is expected to release by the end of January. "John's Fire Witch" by John Baker opens at Ohio State University, where you're on your way to hang out with John Baker himself for an evening of consuming major amounts of pizza and beer. He's a no-show, so you head back to his place and crash for the night, only to awaken to a raging blizzard outside and still no sign of John. As the game continues, you learn John is wrapped up in a struggle between a "Fire Witch" and an "Ice Wizard" that live in a recently exposed underground area far below his Columbus apartment. "John's Fire Witch" is billed by its author as "a good beginner game"; it currently has an expected release date of February 1. +++++++++++++++++++++++++++++++++++++++++++++ INTERVIEW: GRAHAM NELSON +++++++++++++++++++++++++++++++++++++++++++++ Graham Nelson has intrigued thousands of text adventure fans with his enchanting game "Curses", among others. He is also well-known as the author of Inform, a freely distributed, highly portable development system for writing text adventures, and has been involved in advising others on making use of it. Q. How did you first become interested in adventure game programming, and how and when did you get started? What kind of computer do you use, and what programming language(s) have you used in the past? I'm a rather junior pure mathematician at Oxford University, aged 27: I mention my age because I was a child when Crowther and Woods' original "Advent" was being circulated across in the world in the late 1970s. My next-door neighbor, a senior executive at Digital UK, occasionally took me to play at weekends, in a hugely untidy maze of a converted biscuit factory in Reading. I was mesmerized, about 10 being the peak age for imagination. Then in my early teens, when the home computer bubble was blowing, I had one of the first, an Acorn Atom, and used to write primitive adventures on that. (In about 10K of memory, which taught me a lot.) The breakthrough was realizing that one could represent locations with numbers, giving each object a location variable...well, I was young. I still use Acorn machines, which are technically superb: I now have an Acorn Archimedes A5000 (which contains the old Atom operating system the way human DNA still includes that of early grasses). I use two languages, the excellent Norcroft ANSI C compiler and Inform. Q. What was the chronology of events in your development of Inform and Curses? How long did the different parts of Curses' game development and programming processes take? Firstly, I never intended to write Inform! I had played a few Infocom games in the late 1980s (running under CP/M on a ghastly Amstrad), and admired them: I was curious about the run-time format and in early 1993 found some fragmentary documents on the Internet. I wrote to Mark Howell asking if there was a compiler, and he said "Many people have had many dreams". So I tried to fake a toy game file, to print "Hello World" and stop. Each time, nothing happened, and I thought, ah, I shouldn't have missed out the property default table, and coded a bit more. Eventually I found it had been working all along - but didn't show anything on screen until it had the first full page of text. I inserted 30 new lines, and suddenly my toy said "hEllO woRlD". (An hour later I understood alphabet shifting rather better!) My first real program factorized the numbers 2 to 100 into prime factors, for which I improvised an assembler: Mark's excellent disassembler helped me to perfect it. By then "zass", as it was called, was a horrid tangle of exceptions so I sat down with plenty of paper and worked out the underlying rules. I wrote these into a much simpler assembler, added "if" statements, code blocks, loops and an expression evaluator, and the result was Inform 1. The first large Inform program was the hardest one, the parser. I was determined on all the Infocom trappings: asking questions to sort out ambiguities, in particular. Adding everyday Adventure verbs (take, drop, inventory) was simple: finally I threw away my silly test game and began "Curses". I had a rough design in mind already, and in about a fortnight had the attics, the Unreal City and the garden fleshed out. I should really have planned more carefully: for example, the game's least fair puzzle (changing the torch battery) dates from then. Some friends amused themselves finding a bug every ten seconds: I took it away, kept at it for a month or so over Easter 1993 and gave it to Richard Tucker and Gareth Rees to test. They sent me back another hundred bugs, and I filled out the game with a few more puzzles (such as the robot mouse). At the end of April I archived "Curses" and Inform, and announced them on the newsgroups. For a fortnight nobody at all emailed me, or posted a follow-up. Doesn't anyone care, I thought? It turned out my newsreader was broken, and hadn't posted at all. Once the announcements were actually heard, there was a slow but gathering response: by the end of the first year, an avalanche. The first public "Curses" (release 7) was a little over half the present size: the catacombs, Alexandria and the village were missing, for instance, and these were gradually added in later releases. (It's now finished. The very last addition was the maker's mark of my 18th century ancestor, William Snelson the Clockmaker, on the parish clock.) Extensions were possible because Inform was getting better, with the help of real programmers, especially Bob Newell and Dilip Sequeira. By the new year of 1994, it had grown up into Inform 4 and could produce games twice as large. The language was still difficult to write games in, though (I wince when I look at the original "Curses" source code). I decided on a makeover and did this by writing an Inform version of "Advent", working from David Baggett's excellent TADS edition: on the way I improved the cosmetics of Inform until it looked object-oriented and comprehensible. In the nine months since, I've kept the language stable (though the parser has vastly improved) and worked instead on proper documentation: I'm rather pleased with the new manuals. I see Inform now as a gauche young adult, having got past the stage of growing out of his shoes every few months. Q. You've chosen to distribute Inform, as well as your games, free of charge. What was your line of reasoning in making this altruistic decision? At the time the newsgroups had a rather elegiac "all the good games were written years ago" tone, and I hope "Curses" has contributed to a change in that attitude. I wanted to revive the "dead format" of the Infocom game, and persuading people is easier when they don't have to pay to listen to you. In the early Renaissance, Italian artists would wander round Roman ruins and say, well, we can build arches too...and I'm as vain as those artists. There are other kinds of profit. Q. Have you seen any interesting games that others have created using Inform? Yes, but mostly ports from earlier systems, fragments and work in progress (I know about a dozen authors working seriously, and I do my best to help them with technical snags): Inform 5 is still rather new. I do recommend Jon Drukman's witty "Busted", since you ask. Q. Over the past few months, questions about Curses (and pleas for hints) have virtually precluded all other discussion on the interactive fiction newsgroups. What comments/questions do you hear most frequently? Any extremely odd complaints? Remember that "Curses", being free, is circulated much more widely than shareware games (it has reached tens of thousands of players, the approximate sales level of a typical Infocom game at their height), so it gets more than its fair share of attention. It's frequently over-praised now, and I've enjoyed watching a generation of "angry young men" critics beginning to say, well what's so good? The most frequent complaint is that it's hard. True: it's a hard game to win (though surprising numbers of people do, and I tried to put much of the best material in the late middle game, to reward persistence). Also, many people ask me how to use the secret debugging commands, apparently under the impression that I'll tell them. Q. In retrospect, what would you have done differently in designing Curses? I like the eclectic feel of the game, the wide range of puzzles: so I'd keep that, even though it looks incoherent in places (especially to people who miss the better-hidden clues). I might make it a little smaller: as it is, there was a draft which had a good 20 or so extra rooms, but my play-tester Michael Kinyon and I never felt happy about them and I removed two entire regions. (Redrafting heavily after testing, incidentally, is much to be recommended: testing isn't just about bug-fixes.) What I would pay much more attention to are the few points where the player can inadvertently make a career decision. Most players end up back-tracking, though some actually enjoy this. Q. Please describe the demonstration files that showcase Inform's features. First, "Advent", a simple game to implement but still a good one to play. Then there's "Toyshop", a dense little area filled with peculiar objects: examples for expert Informers. "Balances" - which I wrote in one and a half evenings, and isn't meant to be a serious work of art! - is a pastiche of the much-loved "Enchanter" trilogy, partly (I admit) for fun but mostly to demonstrate really awkward "parser" puzzles, such as lottery tickets numbered from 1 to 10,000, and indistinguishable objects which one can write names on. There are also some smaller examples, and a port of Scott Adams' "Adventureland". Q. There has been heated discussion on the IF newsgroups about the difficulty level and fairness of some of the puzzles in Balances and Curses. How do you respond to charges that some of your puzzles violate tenets of your own "Bill of Player's Rights"? Guilty. But in mitigation I do mostly play fair, and am at least properly contrite about the few low blows in "Curses". I try to make puzzles range all the way from easy to hard (most are never complained about), and to leave many open at once. A deliberate choice on my part was for the player to continue to find new possibilities in the early Attic rooms far into the game: I think this builds atmosphere, though it means there's no neat division of the prologue from the middle game. Besides, players very widely disagree (especially with me) about what's hard and what's easy: and in a way, "I won, but it was a fight" is the best compliment a game can receive. Q. What plans do you have for future games? Is a Curses sequel a possibility? I have been working on a more serious game, called "Jigsaw", for about 18 months (off and on), but don't hold your breath: it'll be a while arriving. The time has mainly gone on getting Inform into a decent shape for public use. I suppose the plot of "Curses" makes a sequel conceivable (when compared with, say, the plot of "Hamlet") but none is planned. Q. Who are your favorite authors? And what are your favorite computer games? I greatly admire the poetry of Philip Larkin and Primo Levi, writers who have absolutely nothing in common but their initials. Besides them, Auden, Eliot, Donne, Browning, Elizabeth Bishop: more predictable choices. For plays, Tom Stoppard, Christopher Hampton, David Hare. My favorite novel, I admit it, is John Christopher's trilogy "The White Mountains", "The City of Gold and Lead" and "The Pool of Fire": notionally for (older) children, but infinitely more sophisticated than, say, Tolkien. His prose is not flawless but his plot, characterization and atmosphere are. In my view the best adventure games are "Spellbreaker" and "Trinity", coming up for its tenth anniversary. The modern computer games market depresses me: I think it's become like American TV. Nowadays, an "adventure game" means something like "The Seventh Guest", on two CD-ROMs, about 20,000 times as much code as the original "Advent" and about a tenth as clever or interesting. "Alone In The Dark" is better, admittedly. I had a serious "Tetris" problem at one time. Shoot-em-up games are all very well, but I prefer them abstract - old-fashioned as I am, I find reviews like "I saw tortured POW's, floating (dead) comrades...Great stuff!" (a genuine example) rather disturbing. Q. I've heard a lot about how portable Inform is to various systems because it works with so many interpreters. Would you elaborate? The compiler itself will indeed run on most sensible computers (such as PCs and Macs) but the games it produces will run on practically anything, from personal organizers to mainframes. An "interpreter" is a program which will play an Infocom game file, whether bought from Activision (who currently sell the Infocom back catalogue at very low prices) or compiled by Inform. There are public-domain interpreters for virtually every machine (and it requires little effort to move them to new ones). So there's only one "Curses" program, and it runs identically on dozens of very different machines. Q. What is your view on future directions for interactive fiction? I don't really believe in "directions" in art; the rope twists as you follow it, that's all. The "interactive fiction" format hasn't changed in any fundamental way since the early 1970s, in the same way that the format of the novel hasn't since 1700. (Don't believe the cyberpunks - the majority of authors aren't going to move over to hypertext just because the technology now exists, any more than they did to pop-up books, comics or television.) If pushed, though, I'd say that the next stage will be reached when it it's no longer true that about 75% of the best games were written in 1980Ð85. We're on the way to that. Q. What other work/projects currently occupy your time? What do you do in your spare time? This is what I do in my spare time! I'm a differential geometer and work on low-dimensional gauge theory and topology, at least when I'm not teaching. I've spent the week interviewing would-be students: as I sit typing this at 1 a.m., I'm listening to Bach's "The Art of Fugue". I write a small amount of poetry, rather slowly, but publish little. Q. In the Inform manual, you wrote "the author of a text adventure has to be schizophrenic in a way that the author of a novel does not." What are the most critical issues faced by the programmer in combining storytelling with game design? The single biggest is to stop the player from getting stuck and getting bored; always think like the player as well as the designer. This means keeping many trails open at once, inevitably requiring a fairly "parallel" plot. This plot should be discovered rather than announced, so show, don't tell. Finally, don't forget to throw in distractions and sub-plots. This makes an unconventional story: long on situations which have to be faced sooner or later, short on chains of consequence and changes of heart or attitude. Q. From the player's perspective, finishing a good text adventure game can be a little sad in the same way that finishing a novel means leaving behind your favorite characters. What advice can you give for creating memorable game environments? Atmosphere is enormously important and requires fine crafting. Once a genre has been adopted, stick fairly closely to it. If you're setting a game during the Cuban Missile Crisis, look through a library: find out what people were wearing, what other issues were in the news, how houses were furnished, what cars were being driven. Especially include things which now seem foreign: say, a puzzle which involves dialing somebody's name on a phone whose dial has letters as well as numbers (long since phased out, in Britain anyway). And, as I said before, I like to employ a form of repetition, in which the same elements recur but in different and unexpected ways: rather than being discarded as soon as they are understood or passed over. Q. What are the most valuable things you've learned about designing parsers for your games? To what lengths must a programmer go in anticipating the actions players will attempt? Extremities, I'm afraid. There is no substitute for extensive play-testing. About one-third of the code in a good game will be devoted to blind alleys and responses to wrong guesses by players. I like to code up some ideas of my play-testers as alternative solutions: if they make sense and don't unbalance the plot, why not? As I recall there are now six different ways to open the medicine bottle in "Curses". Writing a really general parser is a major but different undertaking, by far the hardest points being sensitivity to context and resolution of ambiguity. I suppose my main lesson has been not to take shortcuts. Less flippantly, that it is better to write a parser which understands too much (i.e. understands some strangely worded requests which it ought to reject) than one which understands too little (because it has too narrow a grammar). +++++++++++++++++++++++++++++++++++++++++++++ NEWSBRIEFS +++++++++++++++++++++++++++++++++++++++++++++ --------------------------------------------- Zork-based MUDs: Coming to a Corner of Cyberspace Near You --------------------------------------------- People are social creatures, and there might come a time when you feel the need to enjoy the company of others when you gear up to play your favorite IF adventure games. When that time comes, you might want to check out one of the Zork-based MUDs proliferating online. The text-based world of MUDs are a natural for IF fans. Named for multi-user dungeon, a MUD is a real-time online group effort that reflects much of the entertainment that many of us enjoy in solitary: characters acting to accomplish a pre-set mission or acquire treasure, player interaction that could be friendly or combative, new regions where you can boldly go, map and explore. Unlike playing an actual text adventure game - a static, pre-written, pre-coded endeavor - the experience of visiting a MUD is different every time because you're affected by what others are doing online. There are also various categories of MUDs with their own formats; a DikuMUD, for example, has a combat-oriented undertone and a strict hierarchical class system for its characters. How can you find out what Zork-themed MUDs are up and running? A Usenet newsgroup, rec.games.mud.announce exists for just that purpose, offering a forum for new MUDs to broadcast their presence and lodge informational articles about themselves. There are also related newsgroups, such as rec.games.mud.lp and rec.games.mud.tiny, that are all about MUDs that have that particular format, Below, we take a look at two current operating Zork-based MUDs: - ChicagoMUD (telnet to jive.rahul.net 2600) Nino Ruffini operates ChicagoMUD, a DikuMUD derivative that is geographically based in the Zork empire, including such areas as the Barracks of the Antharian Guard, but also borrows freely from many other settings in mythology and history. One of the biggest problems faced in setting it up, according to Ruffini, was "adapting the puzzle-oriented Zork world into a MUD format that is basically hack-and-slash." On the plus side, however, using the DikuMUD format meant that little had to be built from scratch. Ruffini said he compensated by creating solid text descriptions of the world and the characters as a whole. Some 700 visitors have dropped by ChicagoMUD during a recent two-month period. - ZorkMUD (telnet to lestat.shv.hb.se 7890) (temporarily at pine.cs.virginia.edu 7890) home page: http://lestat.shv.hb.se/~zorkmud/ ZorkMUD has been operating on a small scale since the end of 1993, and will open on a larger scale sometime this year, says staffer Tim Hollebeek. "Anyone is welcome to stop by as long as they understand we're still in the building process." In this MUD, the Zork geography will serve as only a backbone for new puzzles built in the spirit of Zork. ZorkMUD is based on a LPmud driver, which means that most of the game must be implemented from scratch. A major issue has been how to accommodate the Zork-type puzzle-oriented games for multiple users. "Questions like 'How can someone start a puzzle if someone else has already finished it? Does it reset itself? If so, do the objects involved move back to where they start? What happens if someone is holding one?' crop up often, and have yet to be fully resolved," said Hollebeek. One last issue, according to Hollebeek, is that ZorkMUD is coded in LPC, which is often too complex for many members of the IF/role-playing/MUSH community with less programming background. ZorkMUD staffers are working on interfaces to help ease the transition. - Stuart Beach +++++++++++++++++++++++++++++++++++++++++++++ 10 HINTS TO GREAT GAME DESIGN by C.E. Forman +++++++++++++++++++++++++++++++++++++++++++++ You've solved every Infocom game ever released. You've FTP'd countless text adventure games from Internet sites in a desperate attempt to quench your insatiable thirst for interactive fiction, but still it's not enough. So you decide to take the final step, to write your own parser adventure. But - how do you know for sure that people will like it? How can you avoid making the same mistakes you've seen in many of the quests you've been playing for years? What exactly constitutes a "good" text adventure game? That's what I'm here to help you with. I've taken it upon myself to analyze my favorite works of interactive fiction, determine why they're my faves, and compile a list of their common characteristics that first-time adventure writers can use for reference. Keep in mind that this is not an article on programming a game. These ten tips deal exclusively with game design and the authoring of the game's storyline. My intent here is to point out the most common mistakes beginners make, and identify methods of avoiding falling into these traps. You may be asking yourself, "Who is this guy anyway? I've never heard of him in my entire life!" True, true. I have been a fan of interactive fiction since I was seven years old, and I have even written a couple of my own adventures. That you've never seen my name anywhere should tell you that my games have fallen prey to most if not all of the problems I'm pointing out in this article. (Of course, I was confined to using BASIC as my sole programming language. Plus I was only twelve at the time.) Right now, I'm working on a couple of new games, and perhaps this time they'll turn out to be quite a bit better. Hopefully you'll be able to learn from my mistakes, too. 1. Develop a good parser. This is the single most important element of any work of interactive fiction. Unfortunately, it's also the one most frequently neglected by beginners. Even the most cleverly designed adventure isn't going to hold players' interest for very long if they have trouble communicating what they want to do. The earliest adventure games, such as the original "Adventure in Colossal Cave" and the Scott Adams series, used crude, verb-and-noun parsers that accepted only two words in each command. Due to the limitations of computers in those days, a standard parser's vocabulary was often very limited, leaving gamers dissatisfied. The Zork Implementation Parser introduced by Infocom in the late 1970s is really the accepted standard for parsers today. If you're using an IF design tool such as Inform or TADS, developing a good parser isn't as much of a problem. If, on the other hand, you've decided to write your own parser, pick yourself up a good thesaurus and use several common synonyms for each noun and verb. Make your puzzles the challenge of your adventure; don't force players to "guess the verb." In addition, the more options you can supply your parser with, the better. An "undo" command, built-in hints, the ability to allow players to configure the function keys as typing shortcuts, and automatic mapping will all contribute to the reduction of frustration on the part of the player. 2. Use good puzzle structuring. Don't just force players to wander aimlessly from one puzzle to the next, halting their progress completely until they solve the only available puzzle. Branch out your puzzle structure and make it as nonlinear as possible. Interweave your puzzles with one another and allow players multiple paths through the adventure. That is, don't make players solve the puzzles in the same order every time; give them some flexibility. The only point in the game where there should be only one path for the player to follow is at the conclusion, where all the branches of puzzles come together to form a final challenge. Puzzle connectivity is also important. Make sure each puzzle "fits in" with all the others. If you have an extremely challenging puzzle, but you can't make it fit logically into your adventure, don't just throw it in for the sake of using it. Save it and use it in another game, where it is appropriate. One of the biggest abuses of this that I've seen comes in the form of mazes. Often adventure writers will simply throw in a maze to make the game more difficult, when in reality it is totally inappropriate and has nothing to do with the game at all. Making maps of games is tedious, and mazes are generally frowned upon in adventure games today, unless they have a truly unique twist (such as the catacombs in "Leather Goddesses of Phobos"), or can be solved without mapping (such as the wet tunnels in "The Lurking Horror"). In summary, designers should ask themselves this: "Is this puzzle connected to the game in some way, or is it in the game merely for the sake of its own existence?" If it's the latter, you should probably consider scrapping it. 3. Balance the difficulty of your puzzles. What's the fun of getting all the way to the end of an adventure only to discover that the final challenge is the easiest puzzle in the history of the universe? In most cases, the best adventure games are the ones that curve the difficulty of their puzzles. Keep 'em fairly simple at first, to allow the player to get into the game, then gradually raise the challenge as players go deeper into it. Don't get me wrong. It's perfectly okay to throw in a difficult or obscure puzzle or two in the early stages of the game, but the key is not to overwhelm the player at the outset. Of course, the primary deciding factor as to the difficulty of the puzzles should be how difficult you've chosen to make the game as a whole. If you're writing for expert players, design your puzzles accordingly. If beginners are your target audience, include a lot of simple, one- or two- step puzzles. In all cases, after a particularly arduous puzzle, reward the player with a few simpler ones. You'd be surprised at how many players lose interest when a game's puzzles aren't balanced. 4. Make your world and puzzles logical This one is basically just common sense, but it's still sometimes overlooked. If you're writing a sci-fi adventure, pay attention to the laws of physics. Don't let players enter the vacuum of space and survive without spacesuits. Realism is less of a problem in fantasy games, as much can be justified by the use of magic. The point, though, is to make sure everything makes sense in some way. This is especially important in the area of puzzles. Avoid making players do things that have no logic or purpose behind them. The more realistic your adventure, the more it will draw players in. 5. Be descriptive. You've created a whole other world, so why not let the player enjoy the beauty of it? How many times have you played a game with such lame location descriptions as "You are in a forest," "You are at the bottom of a tall cliff," "You are outside a cave," etc.? The term "interactive fiction" is not an arbitrary one - players are essentially exploring a form of writing, much like a good novel, and adding their own input to it. So let the player see the world you've created, much like your favorite fiction authors let you see theirs. Take care, though, not to overwhelm your players with prose. If you give them little opportunity to interact, they just might decide that they may as well be reading a book. Don't get too bogged down in descriptions. Usually half the screen is the absolute maximum for a room or object description, and this limit should only be reached on rare occasions. However, if a particular puzzle requires a lot of text in order for the player to see it, one or two full screens are acceptable. (A good example of this case is the mirror box in "Zork III".) Don't make players read the text over and over unless they want to, though. Make sure your parser has the option of changing the length of room descriptions. Using phrases such as "You are in the forest" the second time a player goes there is perfectly acceptable. (Just make sure that players can still get a better description if they want it.) While we're at it, I'd like to mention one variation on this subject. Most players, when writing good room descriptions, like to include several objects or features in each location (for example, a tavern might have a fireplace, a bar, and several tables and stools). Nothing is more aggravating than typing "EXAMINE THE STOOLS" only to be told, "I don't know the word 'stools.'" This is guaranteed to instantaneously shatter the fantasy and destroy any hope of players ever really getting into the game. Do this enough, and you'll alienate them forever. If you're going to put an object in the location's description, you'd better let the player interact with it, even if it's only in a limited way. Just a message saying, "There's nothing special about the stools." will suffice. Incidentally, I feel that this is one of the biggest problems with the Zork-based MUDs I've played. Players see that term, "Zork-based," and they telnet in expecting the same level of realism that Infocom gave us, and unfortunately, they rarely, if ever, get it. I myself have on occasion experienced difficulty in simply trying to interact with what the game claims is in the scene with me, and I'm afraid this is the rule rather than the exception. 6. Be fair to the player. I know, I know. Life isn't fair. Never has been, never will be. But adventure games aren't real life; they're a form of entertainment. And the only way players will be entertained is if they're treated fairly. Here are some general guidelines you should follow to ensure that this is the case: a. Don't let the game get into an unsolvable state too much, without giving the player some indication of it. There's no definite line here, so you'll have to use your own judgment. As an example, consider the KULCAD scroll in Infocom's "Enchanter". (Warning! Spoiler to follow...) You are supposed to use this spell to dispel the illusion of the infinite winding staircase, as this is the only way to overcome this particular obstacle. However, you can also use KULCAD to get rid of the guarded doorway and the Gordian Knot around the jeweled box. If you do one of these, though, the scroll is gone and you can't win the game. Despite the frustration that could be caused by this, I still don't consider it unfair, because if you use the spell on anything other than the stairs, your master Belboz will appear before you and warn you that the evil Krill has been alerted to your presence. You receive a definite hint that maybe there was a better way. On the other hand, I've heard numerous complaints about the game "Curses" because you can inadvertently do something out of sequence and blow any chance of being able to win, and no indication whatsoever is given. So save yourself and your players a lot of trouble, and give some kind of message if they unintentionally do something to get themselves stuck. (On the other hand, throwing all your possessions off a cliff is not a very smart move to begin with, and players should be able to figure this out without a hint. Only tell them they've screwed up big-time if there's a chance they can't determine that for themselves.) Incidentally, a good way to allow players to keep going after they've lost an item is to allow them to re-obtain the item in the place they originally got it. For instance, allow them to pick another apple off the tree if they eat or lose the one they originally got. However, when you're dealing with a unique item, such as the KULCAD scroll, this isn't a feasible option. Again, you'll have to use your own judgment here. b. Don't force the player to have too much foresight. Inventory management is a crucial part of an adventure game in which the number of things a player can carry is limited. Often players will wander into a new location and only be able to take so much along with him. Obviously, if they're going into a dungeon they'll need a light source, a weapon, and probably some food and water, but if they're going to need something less obvious, you'd be wise to provide a hint beforehand. Of course, players can always restore, but going through a lot of moves to get back to where they was before can be frustrating, and too many save files can become difficult to keep track of. It's best to give players a general idea of which items they won't need and thus can leave behind. Don't make them pick and choose too much. A few very good games I've seen are designed so that the player's inventory is pretty much managed as the game progresses. That is, the player uses two items to solve a puzzle, thus removing them from his inventory. Then she finds another object and adds it, and later gets rid of it in another puzzle, and so on. If you have items that don't have multiple uses, this is a good technique to use. c. Don't overwhelm players at the start. If you have a large area they can explore in the beginning, you'd be wise to point them in the right direction to start with. Legend Entertainment's "TimeQuest" is a perfect example of this. With 80 different time-places to visit, any of which can be reached from the beginning, it's vast enough to make the player feel burdened. But this game directs you to Rome in 44 B.C. from the start, which gives them a sense of direction and helps you establish a path through the game. In addition, the most crucial time-places are all listed in the game's documentation, so the player knows where the important places are. This makes it easier to get started. d. Don't put off the entire reward until the end. Congratulate players when they solve a difficult puzzle, possibly by giving them a special item or power. According to Joseph Campbell's monomyth, the challenges a hero faces become more and more difficult as his quest continues, but the rewards become greater. This should apply to adventure games as well. e. Don't create puzzles that absolutely have to be solved within a specific time frame, unless you give the player a reasonable hint. f. Include good error messages in your program to tell players if they're doing something wrong, but don't insult players in the process. Be clever, but not verbally abusive. g. Random events are good for spicing up adventure games, but never, EVER base the decision of whether a player lives or dies upon the outcome of a random-number generator. I mention this because I did it once. The player had to cross a pit by placing a wooden plank over it and then walking across. But you fell in 1Ú3 of the time anyway. Talk about frustrating! The only instance where this is at all acceptable is when there is an alternative solution that is not random. For example, in Sorcerer, players have a 10% chance of successfully jumping a gorge, but if they use a flying spell, they'll get across every time. You might be saying, "Well, this is my game, so I'll do whatever the hell I want, and I don't care whether the player thinks it's fair or not!" Keep sending this attitude, and pretty soon you won't have any players who care about finishing your adventure. Book authors who don't show respect for their readers don't stay book authors for very long. The same holds true for interactive fiction writers. Players are your lifeblood; they keep your game alive. If you want to write games solely for your own pleasure, that's fine, but you won't gain any recognition from doing it. Treat your players as you would treat a paying customer, because after all, that's essentially what they are. 7. Don't be afraid to kill a player off. At the same time, don't hold the player's hand all the way through the game. Let them experience a game death if their actions aren't clever enough. Dying is a natural part of adventure games. Can you picture what the Zork Trilogy would be like without the constant threat of being eaten by a grue in a dark place? And just try to imagine "The Lurking Horror" without death! Which would you rather see after doing something intentionally stupid in an adventure - a detailed, possibly amusing, account of your alter-ego's untimely demise? Or a lame message saying, "That would kill you, so I'm not even going to let you try it"? Believe it or not, it's FUN to try to find new and inventive ways to kill off your character (especially after you've already finished the game). Pampering players with feelings of invincibility is only going to make them severely disappointed. And besides, this is one of the few ways you can get away with murder nowadays. If you've put an UNDO command into your game, don't be afraid to let players use it. 8. Concentrate equally on creating challenges and building the story. Puzzles are fun, but the story itself should be the main point of an adventure game. Rather than having the player wander aimlessly around solving puzzles, develop the story as the player moves along. An unexpected plot twist or the introduction of a new NPC can really liven things up, especially when it occurs in the midst of a good puzzle. Puzzles alone can only carry a game so far. Another thing to keep in mind is that a game should have a good introduction and ending. Actually, an introduction is optional. Some writers may prefer to simply have the game begin as soon as it loads, much like "Zork I", while others may choose to follow the route of "Beyond Zork" and have introductory text spanning several screens. A few games, such as "Zork Zero" and "Demon's Tomb", even have short prologues - opening sequences which play much like the game itself, but which exist for only a limited number of terms. Any of these methods will suffice. A good ending, though, is indispensable. Is it worth struggling through a game just to be rewarded with the words, "Congratulations, you win"? A good game ending should tie up any and all loose ends the story may still have, pave the way for the sequel if you're writing a series of games, and leave players feeling as though they have truly accomplished something. Good endings will be read again and again by players, but I can guarantee that a lame ending will only be seen once. 9. Include good information sources in your game. Most of the time, when writing the game's introduction, you'll want to tell the players only so much about your world. Let them learn the various intricacies and details of it themselves. If your world is vast and complex, build several sources of information into your game to help the player accomplish this. You could implement an encyclopedia (Infocom uses these in several games), newspapers, a computer database, or some other form of information storage (the tape spools in Stationfall come to mind). In addition, you might want to make one or more characters act as primary information sources. The player could then ask those characters about various people, places, or things in the game. The more you tell the player about your world, the more complex and realistic it will appear. 10. Keep the game's longevity intact. A lot of good adventure games become dust collectors after players have solved them. Often this can be prevented, or at least delayed, by a little extra effort on the part of the author. Give some of your puzzles multiple solutions. Think up imaginative ways of dying and humorous tricks for the player to try. Some adventures even have multiple endings depending on various things the player has done (or not done) during the course of the game. All of these things can keep players interested for quite some time after they've been through the entire game. The "Zork" and "Enchanter" series are particularly good examples of this tip. I'm still finding things buried in them that I never knew existed. A little extra programming can go a long way. And there you have it. If you see yourself making any of these mistakes, you might consider rethinking at least part of your original design. Designing a good text adventure is a long, complicated, involving, and extremely frustrating task, but in the end it can be very rewarding. Good interactive fiction is always in demand, and I sincerely hope I have enlightened you and guided you toward successfully creating your own. +++++++++++++++++++++++++++++++++++++++++++++ GAME REVIEWS +++++++++++++++++++++++++++++++++++++++++++++ ------------------------------------ Busted (release 4) Parser: Inform Authors: Jon Drukman (jsd@cyborganic.com), Derek Pizzutto, and Mike Wertheim for Scumbag Software Availability: ftp.gmd.de/if-archive/games/infocom; CompuServe Supports: Infocom ports When you're ready to tune in, turn on, and drop out to play computer games, "Busted" from Scumbag Software is a very appropriate choice. Written in Inform, this release is an updated port of an earlier ADVSYS version by Jon Drukman. "Busted" is set in a collegiate environment where police crackdowns on drug possession are rampant. The game begins as you return to your dorm room and listen to a disturbing answering machine message. The police have just busted your friend Keith and will be on the lookout for you next. In order to save your butt, you need to track down and get rid of Keith's address book, plus any incriminating evidence that you may have left around campus. Along the way, you'll need to solve a series of highly aggravating but rather original puzzles in order to progress to other parts of the game. As in many other text adventures, "Busted" forces you to fulfill some basic human needs - in this case, eating and sleeping - before you can do much else. Beginners are likely to get fed up very quickly. But if you get past this point of the game, you'll probably have invested so much time and effort into solving these two tedious little problems that you'll feel compelled to play it through to the end! After those initial troubles, you must still avoid lingering in dangerous locations or having a bad trip. A little prior knowledge of popular recreational drugs and their effects will take you far in playing "Busted." As I played, my ignorance in this area proved a liability (especially embarrassing because the college I went to had such a pervasive druggie atmosphere). But there are some fun references to popular culture, such as the Cheech 'n' Chong lunch box and the allusions to "Tommy" in the pinball arcade. Many of the puzzles hinge on interacting with or acquiring objects from the numerous NPCs that populate the game. You'll run across other students, workers, mindless bureaucrats, and others in positions of authority. There's also a mysterious stranger roaming the campus, injecting people with a hallucinogenic substance, and even the police are puzzled about his motives. As might be expected, you can't really talk extensively with any of the NPCs, and their characters run pretty true to stereotype. Some, such as the nose-picking Dining Commons line lady, have amusing traits. You'll need to either possess or conceal certain items before accessing several rooms in the game. Most of the locations reflect ordinary college locales, such as a dismal cafeteria, dreary campus center, and an antiseptic heath center. Unfortunately, too few of the items mentioned in the room descriptions could be accessed or described at any length. There are no online hints, which was exasperating when trying to guess the proper syntax for executing an action or the proper order for making a series of moves. In the library, for example, there's no indication that you must put your ID in the computer slot before typing the code for the book you want. I typed first, then put in the ID; when that didn't work, I spent the next hour thinking I must've had the wrong code. If you type HELP, the response begins, "This game is pretty damned easy if you ask me," but does go on to list how to contact the game's author for hints. By far, the most frustrating aspect of playing "Busted" centers on the wildly uneven quality of the parser. For example, when the line lady says "Let's see some ID," why does SHOW ID TO LADY work but GIVE ID TO LADY produces "The Dining Commons line lady doesn't seem interested"? Why does LOOK IN ASHTRAY produce nothing, when LOOK AT ASHTRAY or EXAMINE ASHTRAY does? Complex sentences had to be abandoned entirely. When my efforts failed, I could never be sure if it was because I had the wrong solution in mind or if it was because I hadn't yet hit upon the single acceptable way to phrase that action. Somehow, though, it was enormously satisfying to solve each logistical problem and make even the slightest headway. Despite some initial turbulence, the game is a lot of fun when you get immersed in it. If you can tolerate the limited parser and subject matter, you'll find the game fairly enjoyable. Although Nancy Reagan would urge you to just say no, "Busted" is an entertaining way to enjoy the vicarious thrills of outsmarting the vice squad. - Eileen Mullin ------------------------------------ CosmoServe Parser: Adventure Game Toolkit Author: Judith Pintar (76636.2067@compuserve.com) Availability: CompuServe Supports: AGT ports (PC, some early Macs, Atari ST) If you spend your days compulsively logging on and offline, or if you regularly find yourself at the mercy of your computer for completing an important project by a fast-approaching deadline, you'll appreciate "CosmoServe: An Adventure Game for the BBS-Enslaved." An AGT game written by Judith Pintar, "CosmoServe" combines a compelling story of the perils of a freelance computer programmer with a wry parody of the chat culture found on CompuServe and other online services. As R.J. Wright, a programmer who also fixes indoor plumbing to make ends meet, you have several problems you must solve - and quickly. The major task at hand is completing the code for a program you must deliver to an important client first thing tomorrow morning. You're so seriously in debt (all those CosmoServe charges!) that it may be the end of your business if you let down this client. The clock is ticking, but the code won't compile. Is it a hardware problem or is it the Pascal? And now you've forgotten your new CosmoServe password; how are you going to check your email to see if the technical support sysop has replied to your plea for help? You must also contend with mysterious computer viruses, gaining access to virtual reality mode, fraudulent charges on your CosmoServe account, and a dangerous online stalker. Almost all of the game's 86 locations are online on the CosmoServe service or otherwise in the plane of virtual reality; you can also putter around R.J.'s house or the C: drive on your computer. Examining all the files in all directories on your hard drive is crucial to finding clues, as is entering each area on CosmoServe. The faux DOS interface was as much fun as the inside jokes about CompuServe. I especially liked the replication of CompuServe's electronic mall and being accused of "lurking" on an online conference. You must also keep an eye on the ticking clock so that you can be on time to rendezvous with online contacts at scheduled conferences. The game has some limited sound capabilities, which consist of differently toned beeps for logging on, when a virus takes over your computer, etc. The game's scoring system is vast (up to 1,000 points). Points are awarded generously, even for such actions as reading useful files or messages. The parser does not return a message when points are awarded, so players should keep checking their points in the status line or they may not even realize when or why they've been rewarded. In "CosmoServe," getting ahead hinges upon your ability to absorb information and put it to use. While the initial puzzles are fairly easy, the online portion of gameplay is complicated by malevolent forces such as the online stalker and the impending time deadline. Limited hints are available, nicely incorporated into the theme of online services. When you're logged on to CosmoServe you can type GO HINTS and leave a message for the hints sysop, choosing from an menu of available hints. But naturally, it's frustrating when the question you need help with isn't listed on the menu. Help is also available through a nosy NPC named Aunt Edna, who appears if you have trouble with initial game play and assists with the various steps you must take to find your lost password. Although the game's hints are charitable, they are at best only mild spoilers. And there are still many, many ways to get into trouble. It's extremely easy, for example, for your computer to be destroyed by a virus, or for you to reach your credit limit due to too much shopping or fraudulent charges to your account. You might also find yourself the target of a police sting operation, or so overwhelmed by the VR experience that you conk out for the rest of the night. You can save your game at any point, and it's very helpful to do so, in case of unexpected crises, such as an unauthorized intruder who changes your password and locks you out of using your own account. It can also take a number of false starts or second-guessing your better instincts to decide who you can trust online and whose posts you should respond to. "CosmoServe" was a first place winner in the annual AGT game writing contest for 1992. The game is freeware, but you can register your game by sending the game's author your name, address, and the meaning of life in 20 words or less. It's an excellent intermediate game with broad appeal for all hackers, text adventurers and BBS addicts. - Melissa Katz ------------------------------------ Curses (version 12) Parser: Inform Author: Graham Nelson (nelson@vax.oxford.ac.uk) Availability: ftp.gmd.de/if-archive/games; CompuServe; America Online Requires: ZIP interpreter The family's going on a vacation trip to Paris, France, and everyone's busy packing for the trip. Soon you'll be seeing historical monuments up close and personal, wandering through beautiful gardens, taking pictures for a slide show back home... But wait - there's that tourist map from your trip five years ago. You could save a few francs by digging that old thing up, and you could use a bit of a break from packing. It should only take a few minutes to find the dratted thing in the attic... That's what you think. As the story of "Curses" unfolds, you'll indeed find historical monuments (good as new), beautiful gardens (your own), and slide shows (as you've never before seen them). You'll also find numerous puzzles ranging from simple (not many of those) to difficult (lots) and hair-tearingly frustrating, spread across the years from ancient Egypt to the present. And you will find literary allusions, references to historical events and legends, and a family history that literally meanders all over the map, but remains centered about the ancestral Meldrew Hall in England... "Curses" is rooted in the traditions of Infocom games where you must wander about your house and the various scenes you'll be able to unlock, picking up objects and using them to aid your quest, answer riddles, and above all else, examine everything you see so that you won't miss vital clues. As with other works of interactive fiction, you'll be able to save the game at any point, which will come in handy...You aren't likely to die very often in this game, but some scenes can only be entered once: this means that if you miss something important and realize it later, you'll want to go back to before that scene. "Curses" well qualifies for the title of "interactive fiction" as compared to the "adventure game" which strings together puzzles with little relation to the storyline. Apart from the descriptions, which are generally well written with an eye to atmospherics, you'll find bits and pieces of family lore that weave back and forth across a historical canvas, sewn together by your efforts. When (if) you finish the game, it should all make sense... more or less. Most puzzles depend on the traditional verbs: opening and closing things, unlocking things with other things, pushing, pulling, moving things, inserting things in other things, or turning things on or off. There area few NPCs, such as Austin, Jemima's cat, but don't expect to be able to converse intelligently with them - you can give them things, occasionally - manipulate them in other ways, or ask about various things, but they aren't much for talk. The parser gets most of the things that Infocom games will, but there are some points at which you must use correct phrasing - if you think that something OUGHT to work a certain way, try phrasing it differently or using a different verb. Mercifully, "Curses" manages to be original in its puzzles, which will depend in large part on the history that you can uncover with the help of a few references (some of which are even included in the game). Clues to these puzzles can come from surprising sources, that appear at first blush to be unrelated. (when I say you must examine everything, I'm not kidding) The game's on-line hint system has been personified in the form of supernatural agencies - alas, the hints present are rather cryptic, and if you can't figure out a puzzle from the hint, there won't be any more hints. These agencies also may not recognize some puzzles you want to ask about, which can be frustrating. "Curses" release 12 expands its map and puzzles in many ways over previous versions, which makes this game even tougher and more frustrating. If you can beat "Curses" single-handedly on this version, then you may accredit yourself a most accomplished gamer. If not... Don't feel bad, almost everyone else had to ask for help. There are 550 points, and the score system is annotated - if you ask for a 'full' score, you'll be told what points you got from what source. Some of the annotations can be rather amusing. If you liked the Zork trilogy, and you have a fondness for mythology and obscure things, then you will probably enjoy "Curses". But beware! This is no game where you can sit back and watch the daisies grow - keep your mind sharp, and above all...examine everything. - Conrad Wong ------------------------------------ Veritas (release 1.2) Type: TADS Author: Jim Reese (jreese@leland.stanford.edu) Availability: Released as of 1/1/95. Contact author for more availability information. Supports: TADS ports "Veritas" - which, this game tells us, is Latin for "truth," as well as being the Harvard motto - is set at, where else, Harvard University, as you attempt to meet the standards for graduation. And with standards like these, no wonder I didn't go to an Ivy League school; to graduate (and, not so coincidentally, win the game) you must present your senior tutor with a list of items that ranges from the expected (a senior thesis) to the bizarre (an edition of the Gutenberg Bible), all of which can be obtained through your travels in, around, and under the Harvard campus. The puzzles you must solve to complete this scavenger hunt range from the mundane to the harder-than-average - a couple I wouldn't classify as puzzles at all, since you can easily solve them without even trying. (Others, such as one involving creative uses for a yardstick, are quite clever.) If I have one complaint about this game, it's that there's a bit too much brute searching involved; it seemed like one too many times that I knew just what I needed, but wasn't sure what object I still needed to look behind, or under, or inside to find it. But this is nit-picking, because the true genius of "Veritas" isn't in the puzzles, but in the details. Writer/programmer James Reese has worked up an incredibly detailed virtual Harvard, with intricate descriptions of everything from the tapestries in the Harvard Lampoon castle to the works of art in the Fogg Art Museum (or, after you've swiped them, wry commentary on the sad times we live in that have left nothing but blank spaces on the walls). If you hate red herrings, be forewarned: probably one-third of the items in "Veritas" are there for nothing but atmosphere, but they do a terrific job of providing that - I feel like I came away from the game with a decent understanding of Harvard culture, and even Cambridge geography. I can't wait to meet a Harvard grad now, so I can ask them if there's a statue of John Harvard, "Harvard founder," that depicts another man altogether, the year the college was founded, and even that he was the founder of the college... "Veritas" is a fun play, and well worth the $10 shareware fee which should help encourage Reese, now in med school at Stanford, to finish work on the promised sequel, "Club Med." - Neil deMause ------------------------------------ Odieus Parser: Inform; also available in AGT Author: Inform port by Teo Kwang Liak (bh71139770@ntuvax.ac.sg); AGT version by David Malmberg; original author unknown Availability: ftp.gmd.de/if-archive/games; AGT version on CompuServe GAMERS forum Supports: ZIP interpreter "Odieus" or "Odieus' Quest for the Magic Flingshot" is a much-recycled game, The version currently residing on ftp.gmd.de/if-archives/games was ported to Inform by Teo Kwang Liak. The game (still a beta) was written as an Inform programming exercise; it's a straightforward translation of the AGT version written by David Malmberg some years back, which in turn is an adaptation of a LADS adventure by an unknown author circa 1988. Whew! So, what's the appeal? Why has this game endured for at least seven years? I wanted to see if Odieus was interesting as a game, not just a coding exercise. I also played both the AGT version and the Inform version to see if there were any noticeable differences in play or in difficulty. It's easy to see why "Odieus" is a good choice for experiments in programming. It's a very short game (24 locations) with uncomplicated puzzles and every object in the game (except for a red herring, literally) has a single use. As the game's introduction tells you, your name is Odieus and you come from a long line of sorcerers and enchantresses. You're well-educated in the art of spell flinging, but unfortunately your magic flingshot has been stolen by your bitter archenemy Blackwing. Your mission consists of gaining entrance to Blackwing's lair and discovering where he's stashed your prized possession. You have to get past several guarded locations (staffed by a gorilla, a pride of lions, and a sleeping giant, among others). Solutions tend to involve the arbitrary use of objects, rather than logical ones, especially for the final puzzle in the game. For avid players looking for a new challenge, though, there's little about "Odieus" that's attention-getting. The story is thin, character development is nil, and the puzzles aren't terribly intriguing. In general, magic and sorcery themes leave me cold. But even if you are an fan of "Enchanter"-type games, be forewarned that the sorcery is just for atmosphere and there aren't any scrolls to learn or spells to cast. The best audience for "Odieus" is probably beginning programmers, which explains its many reincarnations. Every language has its own conventions for ensuring that conditions have been met (i.e., objects are present, objects are used correctly), so I'm sure it is a good exercise to translate what must be a fairly simple program (speaking as someone who knows nothing about programming) into your language of choice. I did find the Inform version kind of buggy. My first complaint is that the parser can be contradictory. If you try to chop down a tree with an axe in one room you get the stock response to chopping anything: "Cutting things up in this game is never useful," but a tree does come crashing down one room over when you chop at it. A new default answer is definitely needed. Also, most of the room descriptions failed to list all the directions in which you can go. My biggest problem in playing the Inform port, though, was trying to find the right syntax for solving one problem: cooling off the hot springs. I could do it with no problem in the AGT version, but I couldn't get the parser in the Inform version to accept anything I came up with. So, while I managed to complete the game in the AGT version, I remained stuck at this puzzle (about one-quarter of the way through the game) in the Inform version. The bug is probably something that would be easy to fix. I didn't find these specific problems in the AGT version, but overall the parser in the AGT version was much more frustrating. The vocabulary was very limited and the parser gave few clues if the names you tried to use for objects were inappropriate. In both version of "Odieus" you wind up with 150 points, and you need to get all the points to finish the game. (The AGT version, though, will award you an extra 10 points if you print the order form for buying your own copy of the Adventure Game Toolkit!) While the story of "Odieus" won't keep anyone on the edge of their seat, I'm sure it would be interesting to compare the coding challenges from a programmer's perspective. I'm sure the TADS and ALAN versions won't be far behind... - Lauren Meckler ------------------------------------ +++++++++++++++++++++++++++++++++++++++++++++ Tales from the Code Front - Special Delivery: 5,000 Mailboxes in TADS by Neil deMause +++++++++++++++++++++++++++++++++++++++++++++ Always, it came back to the mailboxes. I am not a computer programmer. Before I decided to learn TADS and finally program the text adventure game I had been mulling over for years ("MacWesleyan", due out any day now), my last programming experience had been in BASIC, on my Tandy Color Computer (with 16K RAM upgrade!) that disappeared into my parents' closet somewhere in the early 1980s. Still, I was doing okay - TADS is a very logical system, and helpfully spits back yards of error messages at you to let you know what you're doing wrong - until I got to the mailboxes. Here's the scenario: A post office in a campus student center. In the post office, a wall covered in mailboxes (5,000 of them, to be exact). Only one of them is yours; the rest are just there are window dressing, and to thoroughly befuddle you until you discover how to find out your mailbox number. All I needed, then, so far as the programming was concerned, was to make two mailboxes, one yours and one not (which would stand in for all the other mailboxes) - or maybe even just one mailbox, which wouldn't let you open it unless you gave it the right number. But how to make an object that would respond to any sentence of the form "VERB mailbox NUMBER"; this was my dilemma. At the suggestion of the editor of this fine journal, I took my dilemma to the denizens of the rec.arts.int-fiction newsgroup. Surely, these programming experts would have come up with code for something as simple as a bunch of mailboxes? My first response, from a well-known TADS programmer, mounted to a list of ways *not* to do it: make "mailbox" an article (which he called "pretty evil"), make "mailbox" an adjective of the object NumObj ("this seems dangerous"). Ultimately, he said I should try to use TADS' Preparse function, a fabulously powerful tool that is as incomprehensible to me as Linear B. My next message came in the form of an e-mail missive from someone in Finland whose name appeared to be entirely made up of random numbers and letters. (I've heard that this is common among European Net accounts. It must be just one of those Continental things that we Americans can't understand, like national health care.) Though this person was undoubtedly well-meaning, his (her?) suggestions were complicated by the fact that his English syntax was about as good as my TADS code - a nice try, but ultimately just leaving me scratching my head and blurting out error messages. Finally, to my rescue rode none other than MJR - Michael J. Roberts, the always-helpful creator of TADS. The obvious solution, he said, was to add an entirely new class of object, numberedObject, that would do what I wanted. Unfortunately, that would require rewriting the parser to handle the new syntax; he'd get back to me when it was ready. Meanwhile, I had hungry beta-testers who couldn't care less about the nuances of TADS code - they wanted their mailboxes, and they wanted them now! I tried various workarounds, including the suggestions that the famous game designer had said were bad ideas. (He was right. They were.) Finally, I simply diverted all action from NumObj while in the Post Office to the mailboxes: now if you typed "OPEN 2000," it would try to open the mailbox with a "value" of 2000, and would only succeed if it was your mailbox, and so openable. For those players who insisted on typing a more sensible sentence like "OPEN MAILBOX 2000," I programmed in a special error message telling them how to phrase their request so that my bad programming could make sense of it. This worked - most of the time. About one time out of ten TADS refused to recognize even properly phrased sentences. I began warning my beta-testers that the mailboxes were a "work in progress." Another week, and another message from MJR. The new parser was ready, and new code for numberedObject. This employed a trick: you could have only one object (in my case, one mailbox), and TADS would make a *copy* of the object, with a value set to the number that was input. This way, a minimum amount of coding could result in a different response depending on what mailbox you specified. This could be it! I got it downloaded, changed the coding... And it crashed. Over and over again. Back to MJR for *another* new version of the parser. Fingers crossed, I ran the compiler, and started up my game. Cautiously I entered the post office. > UNLOCK MAILBOX 2000 It unlocked. >OPEN MAILBOX 2000 It opened. There, inside, was the postcard I had placed there! My long quest had ended! I happily open and shut the mailbox, removed the postcard and put in back inside. Where, as Ensign Chekov would say, "it wanished." Gone, without a trace. The subroutine that deleted the duplicate mailbox at the end of the command sequence had efficiently taken my postcard with it, and there was no getting it back. As XYZZYnews went to press, I was still waiting for an answer from MJR on this latest problem. I'm sure he'll have one - he's a smart guy. Meanwhile, my mailboxes sit there, happily gobbling up anything a hapless adventurer chooses to insert into their gaping maws. Sometimes I wish my parents had never bought me that Tandy in the first place. Ed. note: I'm happy to report that MJR came through in the clutch, the mailboxes now work as planned, and Neil now has only fond memories of his Tandy. +++++++++++++++++++++++++++++++++++++++++++++ SPOILER COLUMN +++++++++++++++++++++++++++++++++++++++++++++ Q. I need to know how to get past the half-formed urchins (that are attached by their heads to a slimy thing below) in the caves below the campus in "Lurking Horror". After steam-blasting the rats, I go down there and they won't let me pass! Plus, every time I try and get the mummified hand from the peach tree, no matter what I do the flier-creature eats it! I can't get away from the roof with it! So: how can I keep the mummified hand? A. To answer your questions in reverse order: have you logged onto the whiz-bang PC in the Terminal Room, where the game begins? If so, you should have the stone that you find in the dream sequence you enter while logged onto the PC. The stone is what you can use to scare off the dark flier outside the skyscraper roof. Just make sure you pick it up again after you use it there... Your second question is more complicated to answer without giving major, major spoilers (despite the title of this column, we don't want to solve everything for you. We just want to give you enough info to get past one little holdup so that you can move on to bigger and better challenges). You're going to need an implement for cutting the wires; the urchin might be able to help you, if you can have the right effect on him. What you'll realize, though, is that you'll need a workaround for getting the cutter down to the basement. These games sure have their ups and downs, don't they...if you still need help at this point, we'll look for you next issue, same bat column, same bat game! Q. I'm stuck annoyingly early in "Monkey Island 2: LeChuck's Revenge". To make the voodoo doll of Largo, I've gotten his hair, his spit, and his ancestor's bone, but I still need to get an item of his clothing. How do I get the ticket to get the clean laundry? A. First, you need to get the bucket from near the laundry. Leave that area and go to the Swamp. Click the bucket on the swamp to fill it with mud. Return to Woodtick and go back to Largo's hotel room. Close the door (note that it won't stay completely shut) Balance the bucket of mud on top of the door, and wait for Largo to return (as he always will when you're in his room). As you might expect, when he comes in the bucket is knocked down and Largo's clothes are ruined. Follow him back to the laundry and eavesdrop on his conversation with the laundryman. Return to Largo's room and look behind the door for the laundry ticket. You can then go and use the ticket to pick up the clean laundry. Q. In "Return to Zork", how do I get milk from the cow, or can I? And what do I do with the witch? A. You'll notice that the reason you're having trouble milking the cow is because your hands are too cold. You need to create a fire and then warm your hands over it. I think you may need to pick up the straw (also in the barn) and then drop it. Light a match and then set the patch of straw on fire. Warm your hands over the fire, then milk the cow. Make sure you have carrots to feed to the cow afterwards. As far as Witch Itah is concerned, she's miffed over a miscommunication with her former beau, Ben Fyshin (the guy you rent the boat from). Before you head over on the boat, show a photo of any female character to Ben; he'll start talking about his relationship with Witch Itah and ask you to give her a letter. When you deliver the letter to the witch, she'll let you take some items from her cave that'll prove very useful to you. Q. In "Cutthroats", I can never shake McGinty and am always killed before the diving expedition even gets underway. How do you get to Point Lookout and the other meetings without him following you wherever you go? McGinty keeps following me, then Johnny gets really mad at me and I'm killed. A. The key is avoiding McGinty when you're carrying your bank passbook. If McGinty sees you while you are carrying it, he will follow you and spoil everything, so you must absolutely avoid him when it's in your inventory. After you get the money from the bank, you can lock your passbook back in your room. +++++++++++++++++++++++++++++++++++++++++++++ WHAT'S ON THE DISK +++++++++++++++++++++++++++++++++++++++++++++ The companion disk for XYZZYnews #1 contains the following game files. It's a good deal for people who have slower modems - at 2400 bps, it'd take about three hours to download the contents of the companion disk. It's also a good deal for people with limited or no access to FTP sites or online services as a source for new games. If you're reading an electronic version of this issue, you can obtain this games disk with a print copy of XYZZYnews #1 by enclosing $3.50 for postage and handling with the coupon on the bottom of this page. If you play and enjoy these games, please pay the shareware fees as applicable. CURSES - An attic-wide search for a tourist map of Paris leads to an incredible journey to 1920s France, ancient Alexandria, sixth century Rome, and other locales. (See review this issue.) Freeware. ENHANCED - Here you are, trying to survive yet another day in the big city with no money, no job and no hope. As you walk down the street in the government research project area, you suddenly see a sign reading: "Volunteers needed for military research project! Do you want to make money? Do you want to help your country? Can you start at once? No special skills needed. Enter here." Everything on the list sounds good to you, so you enter the door and sign up. That's when your nightmare begins... Shareware, US$10. HUMBUG - You are sent to Grandad's for the holidays, but something strange is afoot. Why is there a time machine in the cellar? What would you do with a trombone, a terrapin, and half a pound of lard? Shareware, US$20 or UK#20 (PC disk only) UNNKULIAN 1 - In "Unnkulian Underworld: The Unknown Unventure," you are a slave and apprentice to the ancient wise man Kuulest. After his death, you are the only one who can to retrieve the Orb of Studosity and save the world from the reign of the evil Unnkulians. The first game in the engaging Unnkulian series. Shareware, US$10. VERITAS - Before you can graduate from Harvard in this game, you must complete a scavenger hunt that takes you through a labyrinth of food tunnels, the Harvard Lampoon headquarters, library stacks, and other noteworthy spots on campus. (See review this issue.) Shareware, US$10. +++++++++++++++++++++++++++++++++++++++++++++ XYZZYnews Magazine/Disk Order Form +++++++++++++++++++++++++++++++++++++++++++++ Checks and money orders preferred. Please send coupon with payment to: Eileen Mullin, XYZZYnews, 320 W. 84th Street, Ste. 5B, New York, NY 10024. O Please send me a copy of the print version and companion games disk for XYZZYnews Issue #1. I have enclosed $3.50 for postage & handling. (Check one: Mac disk ___ or PC disk ___ ) O I need just the companion games disk for XYZZYnews Issue #1. I have enclosed $2.50 for postage & handling. (Check one: Mac disk ___ or PC disk ___ ) O Sign me up for a 6-issue subscription. I have enclosed $21 for postage and handling. (Check one: Mac disk ___ or PC disk ___ ) O Please send me a copy of the upcoming XYZZYnews Issue #2. I have enclosed $3.50 for postage & handling. (Check one: Mac disk ___ or PC disk ___ ) Full Name (please print): _____________________________________________ Street Address: _______________________________________________________ City: ________________________________ State: _________________________ Zip/Postal Code: _______________ Country: _____________________________ Email Address: ________________________________________________________