XYZZYnews Issue #18 +++++++++++++++++++++++++++++++++++++++++++++ HOLLOW VOICE +++++++++++++++++++++++++++++++++++++++++++++ Now that I've returned from honeymooning in St. Lucia, I have a few quick bits of advice to fling out to fellow vacationers who are looking forward to finally having some free time for playing computer games. It's all fairly obvious, but isn't hindsight always? * Download all the games you have in mind before you leave home if you have any doubts about the quality or speed of your Internet connectivity at your final destination. Always try to locate a local number for your ISP; otherwise your connection time could make your vacation rather more expensive than anticipated! * Make sure you have all the game interpreters you'll need ahead of time; otherwise, you could face the Internet connectivity woes mentioned above. * Bring along more games than you think you'll need -- they're good to have in much the same way an unread paperback makes all the difference in case of unexpected flight delays. * Don't forget to bring paper for sketching out maps. The amount of hotel stationery provided is usually only enough for mapping one game -- unless you have very tiny handwriting, I suppose! I also want to take this opportunity to lead an early rallying cry for the 5th Annual Interactive Fiction Competition -- see http://www.textfire.com/ for all the details. Programmers can still enter their new games for the 1999 showdown; for inspiration, take a peek at the list of prizes that have been donated to date! Potential beta- testers can still volunteer at this point to help game developers polish their creations. If you're looking to place your votes, you'll have to wait for October 4th; the voting period will take place starting then through November 15th. Until next issue, happy gaming! Eileen Mullin eileen@interport.net +++++++++++++++++++++++++++++++++++++++++++++ TABLE OF CONTENTS +++++++++++++++++++++++++++++++++++++++++++++ Contents: **Top 10 Picks for IF on the Web **Letters **Lessons Learned the Hard Way: Tried-and-True Advice for Creating Your First Game ** Game Reviews: Photopia Anchorhead **Bulletin Board: readers helping other readers +++++++++++++++++++++++++++++++++++++++++++++ LEGALESE +++++++++++++++++++++++++++++++++++++++++++++ XYZZYnews is published by Eileen Mullin, 160 West 24th Street, # 7C, New York, NY 10011, USA. E-mail: eileen@interport.net. URL: http://www.xyzzynews.com/. Send all inquiries, letters, and submissions to any of the addresses above. Contents (c) 1999 XYZZYnews. All rights reserved. Published in the United States of America. Electronic versions: There are currently three 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 by following the links from http://www.adobe.com/. Thirdly, you can also read this issue online at http://www.xyzzynews.com/xyzzy.18.html Subscriptions: All electronic versions are available at no cost. You can obtain either the ASCII or PDF versions by FTPing to the ftp.gmd.de/if-archive/magazines/XYZZYnews directory. To be added to the mailing list, please write to eileen@interport.net and specify text-only or .PDF version. The print version is $15 (U.S.) for one year (6 issues) or $2.50 for a sample issue. For print subscriptions outside the U.S. or Canada, please e-mail or write for rates. All products, names, and services are trademarks or registered trademarks of their respective companies. Editor: Eileen Mullin Associate Editor: Neil deMause Contributors to this issue: Jim Aikin Brendan Barnwell Joe Merical +++++++++++++++++++++++++++++++++++++++++++++ Issue # 18 Top 10 Picks for Interactive Fiction on the Web +++++++++++++++++++++++++++++++++++++++++++++ Adventure Collective http://www.adventurecollective.com/ Christine's Interactive Fiction Page http://www.sff.net/people/JT/cst/IF.htm HyperTADS 1.1b3 http://www.cs.york.ac.uk/~im/HyperTADS/ IF-A-Minute http://spatch.ne.mediaone.net/ifaminute IF News from About.com http://interactfiction.about.com/blnews.htm The Play Infocom Games Cheap page http://underworld.fortunecity.com/track/946/ Quest from Axe Software http://intfiction.cjb.net RANS (Inform game by Bob Reeves) http://www.unm.edu/~rreeves/rans.zip rec.arts.int-fiction Frequently Asked Questions http://come.to/raiffaq/ Robin's Earth: a text adventure game written in JavaScript http://members.xoom.com/_XOOM/robinjohnson/earth/rearth.htm [screen shot of the IF-A-Minute site.] Don't have the time or mental bandwidth for extensive game- playing? Turn to IF-A-Minute for plot summaries. +++++++++++++++++++++++++++++++++++++++++++++ LETTERS +++++++++++++++++++++++++++++++++++++++++++++ IF for Handheld Devices I was reading the article "Have IF, Will Travel: A Primer on Playing Text Adventures on PDAs" in XYZZYnews issue #17, when I came across the following words: "...when you're on the go, you're toting far more portable potential than your fellow commuters armed with Game Boys. So why not have at least as much fun?" I'll direct you to 2 URLs. The first -- http://www.work.de/ nocash/infgmb.htm -- is an Infocom Interpreter for Nintendo Gameboy. The second -- http://bung.simplenet.com/porducts/xchanger.htm -- is for a device that allows data to be transferred back and forth between a Doctor GB card (a writable GameBoy cartridge) and any computer that has a parallel port. So me and my Gameboy have even more fun, I guess. Just thought I'd Inform you (you must get that pun a lot). -- Terence Bowlby x-spectre@home.net Dear Eileen, A good site for Interactive Fiction games converted for the Palm is PalmPilot Entertainment Zone Interactive Games Area: http://www.fortunecity.com/underworld/rpg/22/ Yours, -- Andrew Stables astables@globalnet.co.uk ---------------------------------------------------- Say It with Text Adventures This is in response to the letter of Bob Langer [XYZZYnews #17], specifically, about speech recognition and synthesization in text adventure games: I read an article on Compute! magazine, Nov. 1987, titled "The future of Computer Games: Ten Industry Leaders Speak Out" here is a quotation, from the section "Michael Dornbrook, Infocom": "...'As machines become more powerful, as memory costs go down and things like compact disks come onto the market, you can still have the same type of story, but move away from reading.' "Text adventures without reading? 'Imagine if you could lie in bed and have a voice-recognition system. When you say, "Open the door," you hear a creak or shrieks in the distance. You could play in the dark -- the game would be all aural. You could have great narrators, different voices for different people. There would be a much wider potential market for something like that - simply because there are so many people who don't read.' "Will Infocom be a part of these new media? 'Absolutely. We're interactive storytellers. When we see a medium that lets stories be told, we're going to jump at it.'" -- Alan Manuel K. Gloria alan@i-manila.com.ph ---------------------------------------------------- XYZZY Awards Dear Eileen, Many thanks for your great work on XYZZYnews, as well as the annual XYZZY awards. It is in relation to the latter that I am writing you this. I would like to propose two new awards. The first one, I suggest this simply because I am as interested in the inner workings of IF as in the actual pieces of art that come out of it. And, undoubtedly, we are all depending heavily on having powerful tools. I therefore want to propose a "technology" award. This is to be given to the best and/or most interesting new authoring system, virtual machine, IF- machine port,library routines, a.s.o. published during the year. Perhaps it could even be given to new hardware devices? Sample code for beginners? The second is an "advocacy" award for the most significant promotion of IF outside of the established IF community. Perhaps it could even happen that it's *given* to someone outside of the established IF community? ;-) I am also posting this on r.a.i-f, for "the people" to debate it. All the best, -- Jacob jacob@pop.stud.ntnu.no ---------------------------------------------------- Bulletin Board Responses Hello! [Re Paul Forbes's query in XYZZYnews #17, Bulletin Board] << I know it wasn't the classic text adventure, "Adventure," because it had Ultima I-like vector-based graphics for going into a dungeon, finding a Vampire or Balrog, and seeing its representation on screen. I remember some details about the game, like being ranked with other players based upon the success of your character. >> I think you mean NetHack. NetHack has a simple GUI, but a great IF-like humor (e.g., try the tourist and you will be equipped with a credit card, a Hawaii T-shirt and a camera as "weapons".) The Macintosh port is completely with menus including all commands and even mouse support for moving your character. There are even some sounds hidden, but I never heard them in the game. You can even customize the user interface, e.g., to simulate the good-old terminal look. NetHack is available on nearly every computer platform and I play version 3.2 on my Apple PowerBook with the newest version of the MacOS. I don't know the exact URL, but I would recommend to search NetHack via Yahoo! or write an e-mail to nethack- bugs@linc.cis.upenn.edu. Enjoy! -- Lorenz Szabo LorenzSzabo@csi.com ---------------------------------------------------- Infocom Bugs, continued In issue #17, a reader named Piquan asked a few questions about the following Zork III bug: > DUNGEON MASTER, KILL ME WITH THE STAFF "If you wish," he replies. If you insist... Poof, you're dead! **** The dungeon master has died **** The dungeon master follows you. Your sword has begun to glow very brightly. The game sees that the command is directed at the DM, so it prints out "If you wish," he replies. I think that at this point, in accordance with Piquan's theory, the game temporarily treats the DM as the player and acts as if he typed "KILL ME WITH THE STAFF". At this point, I can think of two possibilities: either the phrase "KILL ME" is reserved as a special case -- where the interpreter skips the standard battle rules (It would be silly to say, "The you parries") and just calls the subject's "suicide" routine -- or, alternatively, any "ME" in this context would be interpreted as referring to the DM. I don't have any experimental evidence, but I'm leaning towards the first possibility; after all, if the second one were true, a command like DUNGEON MASTER, FOLLOW ME would cause the poor guy to start following himself around. Anyway, assuming the interpreter has reduced the instruction to "MAKE THE DM COMMIT SUICIDE", it would rightfully print out "If you insist... Poof, you're dead!", which is the standard output when you commit suicide. Then a different level of the game code notices that the guy just died, and prints out that message. Quick tangent: I bet that when the programmers were writing the make-the-DM-follow-the-player routine, they probably made it work something like this: If the DM is in follow-the-player mode, and he's not in the room, then: * print "The dungeon master follows you" * change the DM's location to match the player's That way, whenever the player moves to a new room, the routine is called. So anyway, now the DM is dead, which probably is internally accomplished by setting his location to some null room. He's still in follow-the-player mode. So the "if" statement is true. So the text is printed out, and the DM's location is set to the room the player is in, so suddenly he's alive again. I have no idea, however, why the sword is glowing brightly. It's only supposed to do that if it's in the same room as an evil object. Then again, maybe the game is smarter than we think -- I'd be pretty scared of an undead corpse, Dungeon Master or otherwise. :) -- Mike Schiraldi mgs21@columbia.edu Dear Eileen, I don't know if you're interested in more Infocom bugs, but I discovered one in the LTOI2 Bureaucracy. After you take the burger in the fast-food restaurant, you can leave (without paying) thru the back door, go around and come back, deal with the waitress, go out back again, go back around again, and order from the waiter. He will then bring you another burger, which you can take, but you will still only have one burger. -- John David tonyscam@email.msn.com +++++++++++++++++++++++++++++++++++++++++++++ LESSONS LEARNED THE HARD WAY Tried-and-true advice for creating your first game by Jim Aikin (jaikin@pacbell.net) +++++++++++++++++++++++++++++++++++++++++++++ One of the things I love about the IF community is the do- it-yourself vibe. If we took a survey, I'll bet we'd find that more than half of the folks who play text-based adventures have at least thought about writing their own game, or even drawn a map. Many of us have downloaded a software development system at one time or another, if only out of curiosity -- to see just how tough it would be to turn our wild-eyed ideas into a real game that others could enjoy. In January of '99 I decided to take the plunge. Six months later, my game -- a large, puzzle-studded story called Not Just an Ordinary Ballerina -- is in beta, and the bug reports are rolling in. Along the way I did a lot of things wrong, and a few things right. If you've ever thought about going this route, maybe I can save you a little pain by sharing some of the lessons I've learned. Not so much about the specifics of programming or dreaming up effective puzzles -- though I learned a lot about that too -- but about how one approaches the process. And if you're happy as a clam letting others do the hard work of making games, maybe you're curious about the sort of contortions programmers put themselves through. The ideas below do not all originate with me. I've benefitted immensely from reading online essays by others. But now that I've done it myself, I have a keen appreciation for what those other writers were talking about. I've been using Graham Nelson's Inform software, by the way, but all of what's said below should be just as applicable to developers using other systems. -------------------------------------- 1. You can't beta-test your own code. -------------------------------------- You can (and must!) alpha-test your own code, to make sure it does what you intended it to do, and to spot all the errors you can. But in a thousand little ways, not to mention a few big ones, you will fail to notice problems that others will stumble over. These problems come in several flavors. First, you'll miss some obvious verbs. I implemented 'shoot revolver', but never considered the obvious synonym 'fire revolver'. (And here's a technical point of the sort that programmers have to foozle over: 'shoot' and 'fire' are not true synonyms. The input 'shoot thief' is NOT the same as 'fire thief', so each verb needs its own grammar, even though both end up triggering the same action.) Second, since you know how the puzzles are supposed to be solved, you won't think of three-quarters of the ways that your players will try to poke and prod at the objects they encounter. Since there are no objects in Not Just an Ordinary Ballerina that can be pushed over or pushed from place to place, it never occurred to me to test 'push trash can'. The only pushable objects, as it happens, are number buttons. When my testers tried pushing the trash can, they gleefully reported that the game responded, "Sorry -- please enter one digit at a time." Big oops. Third, you probably have an idea about what order players will solve the puzzles in. And you're probably wrong. They may (depending on how you've designed the game) find the rusty iron key and opened the creaking door before or after they've crossed the swamp and met the talking alligator. This may have important consequences. The alligator might fail to notice something obvious about the player's appearance. Worse, the game might easily become unwinnable. Fourth, quite likely your room descriptions will refer to objects that testers will want to pick up, examine, open, climb onto, eat, and so on. Since you know those objects are strictly scenery, you may be tempted to just write the room description and get on to the more interesting part of the code. Your testers will mercilessly demand that you finish the job. And by the way, writing a short but convincing explanation of why the player can't carry the garbage can over to the broken drain pipe and climb up on it is likely to tax your ingenuity. You may end up deciding that it's easier and more realistic to implement that action as an alternate solution to the drainpipe puzzle. -------------------------------------- 2. Do a complete walkthrough before beta-testing begins. -------------------------------------- I had tested each of the puzzles and rooms individually after I finished coding it. So of course I knew everything would work, right? Wrong. In my walkthrough I found three fatal errors -- bugs so serious they would render it impossible to win the game. One error was a door that I'd forgotten to give a name. During the initial phase of development, I had left all the doors standing open so I wouldn't have to constantly be unlocking and opening them while I was running around in my little world. It was only in the walkthrough that I tried "open lamp store door" and got "You can't see any such thing." That one was simple to fix; the other two were much worse. -------------------------------------- 3. A good beta-tester is a gift from the Almighty. -------------------------------------- Good testers will bring up all of the issues I've just touched on, and more. They will point out things that confused them. They will tell you when they get, as one of my testers said, "very, very, VERY annoyed" by a puzzle or some other condition that you've set up (either deliberately or accidentally). They may also, if you've done a good job, cheer you on by telling you how much they like the game. This will help a lot when you're suffering an acute attack of embarrassment because you forgot to implement any exits at all from one of the rooms, or failed to notice that when objects were dropped from the top of the telephone pole, they STAYED at the top of the pole (hanging in mid-air, one presumes) rather than plummeting to earth. Treat your testers courteously. Tell them you appreciate their hard work. Respond in a timely manner to their bug reports, and thank them for finding problems. To whatever extent you can, don't be defensive. Even if you think a tester has suggested something ludicrous, something that would weaken the game, I recommend responding, "That's an interesting idea. I'll think about it." Not that any of MY testers have suggested anything like that -- I'm just saying, if they did. -------------------------------------- 4. Be as systematic as humanly possible. -------------------------------------- Draw maps. Make charts. Keep lists. I did as much of this as I could, but inspiration kept getting in the way. My lists would become obsolete, and then I had to decide whether to take the time to update the list, or whether to spend the time actually working on the game. Months later, I'm sitting in front of the computer thinking, "Did I call that object Winter_Coat, Coat, or Overcoat?" I'm wasting more time opening up various files of source code and searching for text strings than I would have if I'd kept a good, alphabetized list. Yes, I did draw a good map. But the names of the rooms in the map don't always correspond with what I called certain rooms in the code. Bad idea. Hair-pulling ensues. Also, for quirky reasons, I drew the map upside down, with south at the top. If there are no rooms with mixed-up exits, it's a miracle. Right now I'm debugging. Do I have an up-to-date "to do" list of fixes that need to be implemented? Nope. I look at a complaint in a bug report, start fixing it, think of three more things I really OUGHT to do, do two of them while I'm thinking of it, get up to make a cup of tea... and two days later I can't remember whether I did the third one. Doubtless you'll be better organized than this. One system that did work well for me, early in the design process: I created a flow chart showing the order in which the puzzles needed to be solved. The beginning of the game is at the top of the page, and various lines flow down the page with cryptic names showing where the puzzles are in the logical flow. For example, you have to solve the fallen beam puzzle in order to get at the object with which to solve the rats puzzle, and until you've dealt with the rats you won't have access to the model train. So there's a vertical line running down the page that has the beam near the top, the rats in the middle, and the train near the bottom. This kind of chart will show you instantly if you've created a circular logic situation, in which you have to solve A before B, B before C, and C before A, thus rendering the game unwinnable. It's also a good way to check that you're giving your players a variety of puzzles that they can work on at any given time. If you've got one long line running down the middle of the page, with no side- branches, players are likely to get bored. -------------------------------------- 5. Some coding will become obsolete long before the game is finished. -------------------------------------- Especially if you're developing your first game (or maybe your second or third -- ask me again next year), your concept will grow and change in major ways as you go along. Ideas -- both organizational ideas and actual puzzles -- that seemed good at the time will prove unworkable. New ones will occur to you, but may prove difficult to implement, given what you've done already. Efficient ways of organizing the development process will occur to you only after you've spent weeks blindly blundering forward and making a mess of your code. -------------------------------------- 6. Consider the design of any complex software object VERY carefully. -------------------------------------- I learned this the hard way. Here's a simple example, which could be elaborated tenfold: If the player has switched off the TV already and then pulls the plug, you don't want the software to report, "The TV screen goes blank." The screen is already blank. But if the TV is on when the plug is pulled, "The TV screen goes blank" is the desired output. So the cord object needs to send a message to the TV object, saying, in essence, "I've been pulled." The cord itself doesn't print out a message at this point, because it doesn't know what the current state of the TV is. The TV object decides whether to print a message. It reports back to the plug object -- probably returning a 'true' from the function that was called by the plug object if it printed a message and returning a 'false' if it didn't. If the plug object receives a 'false', it knows that it still needs to print its own message, but if it receives a 'true', it knows that the player has already been given the correct message. No, wait a minute -- what about the SCREEN object? Is that different from the TV object? If so, shouldn't the TV object tell the screen object to go blank and then report its state to the player? How many layers of code will the pull-the-plug action have to pass through? A couple of the objects in my game can get into as many as a dozen different states. In trying to keep track of it all and print out the proper messages (while learning Inform at the same time) I wrote some really messy code. I may end up having to rewrite a couple of objects from scratch before I release the game. I hope I won't have to, because I'm no longer 100 percent sure what some of those functions are doing. Which reminds me... -------------------------------------- 7. Comment your code. Comment your code. Comment your code. -------------------------------------- -------------------------------------- 8. The combinatorial explosion is real. -------------------------------------- I love that term, and throw it into casual conversation whenever I can. What it means to a game designer is this: Every time you add one object to the game, you have to consider how it may need to interact with every other object in the game. In essence, by adding one object you're potentially DOUBLING the number of interactions that may need to be allowed (or disallowed, with appropriate "you can't do that" messages). Add two objects, quadruple the number of interactions. Add three objects, multiply by eight. In practice, the problem isn't quite that bad, but it's entirely bad enough. At some point in the development of my game, I decided that one of the puzzles would involve climbing up a stepladder, so I added a stepladder object that could be carted around. Then I realized that the stepladder would create an unintentional solution to a second puzzle (which involved a hole in the ceiling), so I had to decide whether I wanted to allow that, and if not, how to prevent it. By now the stepladder can be used in four different ways -- and if my testers suggest any others, I'll have to implement them as well. I could go on about that darn ladder all afternoon: If the player sets the ladder down and then types 'up', that's the same as 'climb ladder'. But if the location happens to be one where there's also a flight of stairs you can go up, will the player climb the ladder or go up the stairs? What happens if the player tries to climb the ladder while playing the bagpipes (which requires both hands)? It's messy. For EVERY container, you have to think about ALL of the objects that players may try to put into it. Got a coffee cup in your game, and a can of gasoline? Be careful, because somebody is going to type 'pour gas into cup' followed by 'drink'. The response, "Ah, fresh-brewed French roast" is not going to endear you to players. And what happens if they carelessly put a full cup of coffee in the rucksack? Will it spill? Are you going to give every other object in the game a soaked_in_cold_coffee variable? I hope it won't come to that. For everything breakable, you need to think about all of the ways it can get broken. If you have a fire source, you have to consider that the player may try to ignite any other object in view. The default response, "That's plainly not flammable," is fairly silly in response to 'burn the scrap of paper'. Ultimately, full verisimilitude is not achievable -- not in a text game and not in any other kind of IF, either. There will ALWAYS be objects in your software- modeled world that the player will try to pick up, examine, taste, or smell, only to learn, "You smell nothing unexpected," or, worse, "You can't see any such thing." But if you do your job right, your miniature universe will be deep and involving enough that players won't really mind. They'll have plenty of other things to try. [Jim Aikin is the senior editor of Keyboard magazine, and an expert on music software and hardware. He is also the author of two science-fiction novels, Walk the Moons Road (Del Rey, 1985) and The Wall at the Edge of the World (Ace, 1992).] +++++++++++++++++++++++++++++++++++++++++++++ GAME REVIEWS +++++++++++++++++++++++++++++++++++++++++++++ Photopia Parser: Inform Author: Adam Cadre Requires: Inform run-time interpreter URL: ftp://ftp.gmd.de/if-archive/games/ infocom/photopia.z5 Response to the XYZZY command: "That's not a verb you need to use." Warning: The following review contains blatant descriptions and analyses of elements of the game Photopia. The review will almost surely spoil the game for you if you have not played it. Ever since I was old enough to be cynical, only one work of art, of any kind, has ever made me cry. (It was a rather mediocre book). And even then, I was barely that old. Since I was old enough to notice and revel in my cynicism, only one book has even come close to making me cry -- and that was The Great Gatsby. Photopia, Adam Cadre's recent game, however, brought me just as close to tears as Gatsby did. Photopia is an amazing piece of work; it has incited both criticism and praise for its masterful focus on story rather than on puzzles -- or, to use the popular analogy, on fiction rather than on interactivity. Because of this, its detractors have scorned it as being "not a game at all," and its supporters have hailed it as a breakthrough in the medium. In a sense, both allegations are correct, and even self- predicting. Any game which breaks new ground (and Photopia does), can be considered a "non-game" using the old standard. But the details of the "theory" of interactive fiction are neither pertinent nor illustrative to this review. Photopia is at its best when it is viewed alone, without preconceptions. The unusual nature of the game is apparent from the outset. The first screen displays "Photopia by Adam Cadre" in the status line, and then a sudden question: "Would you like color?" "What?" asks the inveterate IF player. "Color?" An unusual beginning to be sure; but this is only one of many surprises. It is difficult to attempt an analysis of the story's structure. Where do I begin? Where does the story begin? Where do I end? Where does the story end? These questions are unanswerable, but, on closer inspection, it seems they are irrelevant. The very power of the story is derived from the fact that events are not presented in any discernible order. In fact, the work as a whole is almost impossible to piece together after only one run through; one almost has to play it several times just to understand exactly what is happening when. Moreover, no portion of the game can be completely understood until its relationship to some or all of the others is realized. For example, the first scene of the game -- the frat boys driving through town -- begins abruptly, ends abruptly, barely develops the characters at all, and seems totally disconnected from the next few scenes. But once the entire game has been played (or played twice, or three times), this scene can clearly be seen to have two purposes: First, it draws the player (reader?) into the story with an unexplained tragedy; and secondly, it lends emotion and explanation to Alley's death later on. A young, brilliant girl's death in a car accident is already tragic; when another element is added -- the fact that the drunk, totally guilty, and apparently altogether useless frat boys are not injured at all -- the tragedy is multiplied many times. The two "endings" of the story also complement each other. In chronological order, the earliest segment seems to be the segment which ends the game (the crib scene). Thus, the last scene of the game is actually the beginning of the story. When this is recognized, a whole new pattern emerges: The story can now be seen as a transition from the happy baby Alley, full of potential, to the teenage Alley, dead, her potential destroyed. Another connecting link is the Photopia itself. The entire game is itself a series of intersecting images, paralleling the Photopia. So from one perspective the "real" Photopia (the events of the game) begin when the game begins, and end at the last scene. This last scene, however, is the scene in which the Photopia is introduced. (It is briefly mentioned, but tantalizingly not described, earlier in the game.) Again, the beginning is the end. Likewise, the end is the beginning. The initial scene with the frat boys occurs, chronologically, at exactly (or almost exactly) the same time as Alley's death. So this beginning is itself an end (the end of Alley's life). Continuing this comparison, the scene which ends the story chronologically (the scene in which Mr. Mackaye wakes up in the hospital) provides yet another contrast with the ending as seen by the player (the crib scene). Whereas the "real" ending (the crib scene) has a message of hopefulness (albeit shattered hopefulness), the story's ending has a dark tone. The final words are: "And suddenly the room seems colder...". These examples are clues to the more subtle duality of the entire work. In fact, when we take a step back and examine the story from outside, we see pairs everywhere. Everything seems to have a doppelganger somewhere. There are two timelines: The "real" timeline (the order in which the player sees the game), and the story's timeline. Like the Photopia's circles, these timelines move independently of each other, but influence each other. The crib scene would have been much less effective if it had been placed at the beginning of the real timeline, as it is in the story's timeline, because Alley's character would not have been developed, and the contrast between her potential now and her tragic death later would have been reversed. (Somehow, seeing a death and then musing on its tragedy later is much more moving than musing on the tragedy of a death that has not yet occurred.) There are two stories: The "real" story (the events set in the real world) and the bedtime story. Again, these two can be associated with the Photopia. In the bedtime story, the hero (Wendy) crashes, and then flies later. But in the real story, Alley (the hero) is just on her way up when she suddenly comes crashing down. These two interlocking sequences recall the Photopia's intersecting circles. There are two kinds of color: The "real" colors (black and white) and the "fantasy colors." The real colors are stark, unremarkable. The fantasy colors are vibrant and full of life. Thus, the contrast between the real world and the fantasy world is emphasized. And there are even two cheerleaders with Alley in the gym scene. Among these numerous pairs, the connecting link is the Photopia. Its traveling circles mirror the perambulations of the various characters and storylines. Appropriate, then, that its name is the title of the game. The actual prose of the game is extremely moving. Nearly every scene leaves the player with some emotion. Then the next scene suddenly begins anew, leading up to another emotion. The final sentences of the scenes could be collected as a series of memorable lines: "I wanted to see if the water looked the same UNDER the water as it does OVER it." "You can't help but feel a little sad about that." "...it was green, it was green." Overall, though, Photopia is a work whose strengths and weaknesses can not be accurately identified. No one aspect of it is either good or bad. Is this itself a strength? Or is it a weakness? Or is it neither? Perhaps, as with the story itself, it is not the parts individually that matter, but the net result, the whole. -- Brendan Barnwell BrenBarn@aol.com Anchorhead Release: version 5 Parser: Inform Author: Michael Gentry Requires: Inform run-time interpreter URL: ftp://ftp.gmd.de/if-archive/games/zcode/anchor.z8 Response to the XYZZY command: "Stop living in the past, man." Anchorhead revolves around an ancient cult that worships a nameless god. Somehow, you and your husband (yes, this is one of the few games where the player is female) wind up in the center of it. You must learn more about this cult and discover their evil plan before they destroy. You must be careful with every move you make. The game is not forgiving if you make a mistake, adding to the realism and difficulty of the game. Anchorhead is based on the works of H.P. Lovecraft, whose writings have been the basis for some other classic games as the "Alone in the Dark" series. His works have an unusual flavor of terror that is reflected in this game. In case you've never read any of Lovecraft's works, every act contains a quote from Lovecraft. Even if you have played the game through and bea