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
[email protected]
+++++++++++++++++++++++++++++++++++++++++++++
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:
[email protected]. 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
[email protected] 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
[email protected]
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
[email protected]
----------------------------------------------------
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
[email protected]
----------------------------------------------------
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
[email protected]
----------------------------------------------------
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-
[email protected].
Enjoy!
-- Lorenz Szabo
[email protected]
----------------------------------------------------
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
[email protected]
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
[email protected]
+++++++++++++++++++++++++++++++++++++++++++++
LESSONS LEARNED THE HARD WAY
Tried-and-true advice for creating your first game
by Jim Aikin (
[email protected])
+++++++++++++++++++++++++++++++++++++++++++++
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
[email protected]
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
