* * * * * * * * * * * * * * *
GAMES REVIEWED IN THIS PART:
The Lost Kingdom BFe, by Jon Ripley
Palace of Shadows, by Christos Stogiannopoulos
Space War!...and the PDP-1, by Paul Allen Panks
The Escape, by Anonymous
Escape from St. Mary's, by Ryan Menezes
REVIEWED BY:
Greg Boettcher
Daphne Brinkerhoff
David Whyld
- - - - - - - - - - - - - - -
A more attractive version of this review collection is available at:
http://www.gregboettcher.com/games/reviews/noncomp2005/
* * * * * * * * * * * * * * *
THE LOST KINGDOM BFE, by Jon Ripley
Platform: brainf*ck
Author's web site:
http://jonripley.com/
Download:
http://jonripley.com/i-fiction/games/LostKingdomBF.html
Reviewed by Greg Boettcher
[This review was previously published in SPAG #43.
http://sparkynet.com/spag/backissues/SPAG43
Reprinted with permission.]
I'm not sure why I like The Lost Kingdom, Brainf*ck Edition. Its parser
is crude in the extreme, and when you play it, you spend a lot of time
mapping out mazes. That's not exactly a recipe for success. However,
within the modest constraints of what this game tries to do, it is very
well polished and playable. It's also rather amazing from a technical
point of view, and it comes with an interesting backstory. For all of
the above reasons, I think it's worth a play.
The Lost Kingdom was originally entered into the 1st Annual 1 to 2K
Classic Text Adventure Competition, back in 2004. It took first place
out of six games, and the competition organizer, Paul Panks, called it
"head and shoulders above any game thus far!" This new edition of the
game is not just a new port of the game, but a considerable expansion
of it. The new version has new features, better descriptions, and one
or two new puzzles, in addition to the distinction of being written in
an esoteric programming language.
Jon Ripley claims that this game is "probably the first ever piece of
interactive fiction written in an esoteric programming language and
probably one of the largest non-trivial Brainf*ck programs ever
written." Indeed, the game is written in brainf*ck, which does make it
rather remarkable. Brainf*ck is an esoteric programming language, a
fully functional language, but one that is not at all designed to be
practical, instead aiming only to be amusing to programmers due to its
extreme minimalism. In Brainf*ck programs, there are a maximum of eight
commands, each of which are represented by a single character. (For
more information, see http://en.wikipedia.org/wiki/Brainfuck.) Thus,
the first line of the source code of The Lost Kingdom BFe looks like
this...
[-][.]>+<+[>[>[-]+<-]>[<+>>[-]>>>>>>>[-]+>>>>[-]
<<<<[>>>>+<<<<-]<<<<<<<[
...and the remaining 29,000+ lines of code look rather similar. The
code is thus nearly inscrutable, and so it is not hard to figure out
how brainf*ck got its name. Obviously, Jon Ripley found a way of
machine-generating all this code, but the game is still quite a piece
of work from a technical point of view.
The parser in this game is more crude than any I've ever seen. In the
game's documentation, that author claims that a full-blown two-word
parser might have made the program run too slow on some computers,
given the very sub-optimal efficiency of brainf*ck. As a result, Jon
Ripley has set up a system where all nouns are referred to not by a
word, but by a number. Thus:
You can see:
a small wooden box of matches sitting on the table. (2)
To pick up the matches, type "take 2". At first this seems awkward and
annoying, but there is an advantage here. Every verb has a one-letter
abbreviation, and you can issue commands of no more than two
characters. "t2" is an easier way of picking up the matches. Once you
get used to the verb abbreviations, the system has a kind of simple
elegance. Nobody will extol the game for giving you a feeling of
complete freedom -- you can't use more than 22 verbs -- but within its
constraints, it works well. By the way, it is worth noting that this
brainf*ck edition of this game allows you to save, making it much
preferable to the version in the 2K Comp.
Likewise, the game's help menus are well-designed, as are the menus
that provide the backstory. Speaking of which, the backstory is another
of the game's great virtues, one that is shared with the original
version of The Lost Kingdom. Although the game itself is very simple,
even crude, it is surrounded by a very interesting backstory that gives
the story more depth. (And you should definitely read the entire
backstory if you want to win.) You can read all this at Jon Ripley's
web page for the game's 2K Comp version --
http://jonripley.com/i-fiction/games/LostKingdom.html -- or within the
game itself, by using the "!" command.
There is one other technically interesting aspect of The Lost Kingdom
BFe. It is actually two games in one. When you begin the game, you get
a chance to play it with either "short descriptions" or "long
descriptions." The "short descriptions" version closely resembles the
original 2K Comp version of the game, while the "long descriptions"
version has much longer and more atmospheric room descriptions, as well
as one or two different puzzles.
That just leaves the game itself. Well, what can I say. You pick stuff
up, you manipulate the stuff with the 22 verbs, you wander into a cave,
you map out a couple of mazes, you defeat the bad guy (albeit a bad guy
who is unusually well-characterized in the game's backstory), that sort
of thing. The game itself says, "This game is intentionally written as
a classic model text adventure game." Either you can get into that, or
you can't.
Anyway, in short, this game is pretty bad in some ways. In other ways,
however, it's very impressive. I recommend reading the backstory, and
if that sounds interesting, then this game is probably worth a play.
- - - - - - - - - - - - - - -
PALACE OF SHADOWS, by Christos Stogiannopoulos
Platform: Java
Download:
http://caad.mine.nu/modulos.php?modulo=descarga&id=1209
Reviewed by Daphne Brinkerhoff
[This review was previously published on rgif.
http://tinyurl.com/cv7na
Reprinted with permission.]
This game is best described as "short and sweet". Lonely, you have
locked yourself inside your palace, but now wish to open the gates to
let in your delivering hero. The small size and atmospheric language of
the game faintly reminded me of The Moonlit Tower. This game was
originally intended for the 2K Classic Text Adventure Competition, but,
due to a miscommunication with the organizer, was not entered. Because
of the size constraint, I was expecting unimplemented verbs and
objects, and found a few (nothing that impeded gameplay), but I was
also pleasantly surprised that things like "verbose" and "oops" worked.
I found the few puzzles to be easy, but the author has included a
walkthrough for those who need it.
There's a surprise ending of sorts, which wasn't really foreshadowed in
the game, but it doesn't seem too out of place. All in all, I didn't
find anything I would consider to be a flaw. Recommended for a
fifteen-minute diversion.
- - - - - - - - - - - - - - -
SPACE WAR!... AND THE PDP-1, by Paul Allen Panks
Platform: MS-DOS
Author's web site:
http://www.geocities.com/dunric/westfront.html
Download:
http://baf.wurb.com/if/game/2783
Reviewed by Greg Boettcher
[This review was previously published in SPAG #43.
http://sparkynet.com/spag/backissues/SPAG43
Reprinted with permission.]
If you played the games in IF Comp 2005, you may have played Paul Allen
Panks' game Ninja 2, which took last place in the comp. It begins with
a dragon who is programming a PDP-1 computer and shouting "Spacewar!"
If you looked at this and thought it was sort of weird and irrelevant,
then you may not have realized that the "Spacewar!" remark was a
reference to this game. Well, okay, it was still pointless and
irrelevant. Nevertheless, just in case you're interested, it was a
reference to this game. So what is this game like?
Some people complain that Panks' games are all full of generic fantasy
cliches. If you are among these people, then you should know that this
game is not in some castle or dungeon, but is set solidly in the real
world -- specifically, on the M.I.T. campus in the year 1962. The goal
of the game is to locate a tape of the then-new computer game Spacewar
and find a way to play it on M.I.T.'s PDP-1 mainframe computer. Of
course, to do that, you have to kill a dragon that inhabits M.I.T., and
maybe deal with the campus werewolf too. But mind you, such combat is
only the means to an end. The main purpose here is to play Spacewar. In
such a way does this game depart from the usual dragon-slaying
conventions of Paul Allen Panks.
Oh yes, and I forgot. In this game, you are Master O'Ryoko, a "ninja of
peace." Also, sometimes another ninja will come from out of nowhere to
fight you. Therefore, let no one say that this game does nothing to
escape from the drab, boring atmosphere often to be found in games set
on college campuses.
I wish I could say that this game is better implemented than many of
Panks' earlier efforts, but I'm afraid I can't. Few verbs are
recognized, and none of the items mentioned in room descriptions can be
interacted with at all, unless they are listed individually as
something "you see." Basically, if you can't take it or kill it, you
can't do anything with it, with only two exceptions. This is a step
down from the likes of The Golden French Fry, which Panks at least had
beta-testers for.
Maybe the weirdest thing about this game is the scoring system.
Sometimes your score goes up or down based on your achievements, but
more often it depends on verb usage. If you want to boost your score,
just take something and drop it repeatedly. Each time you do, you get
ten points for taking it and four more for dropping it. Taking
inventory gets you two points every time, and examining anything is
good for three points (even if you just type "examine asdf" or just
"examine"). However, be sure not to use a verb the game doesn't know,
such as "wait" or "listen" or "put," because then your score goes down
by ten points.
In conclusion, if you liked Ninja 2, you'll probably love Space War!...
and the PDP-1. But, oh wait, based on IF Comp statistics, there is
roughly a 0% chance that you liked Ninja 2. Well, anyway.
- - - - - - - - - - - - - - -
THE ESCAPE, by Anonymous
Platform: HTML
Author's web site:
http://www.allthingshappy.com/
Play it online:
http://www.allthingshappy.com/members/allthingshappy/viewInteractive.aspx?writingID=9
Reviewed by David Whyld
An online HTML game. I'm not too keen on the interface which displays
the current text at the top of the screen, then the room description
and a list of characters and options further down. I seemed to spend a
while every time an option was selected scrolling down the page past
the room description that I'd already seen a dozen times to get at the
new options. Wouldn't it have been better to stick the room
description, once its been seen for the first time, down at the bottom
of the screen and have the options displayed at the top? Other than
that, the interface is passable although as with the other online games
I've played there's a noticeable lag between clicking on an option and
the screen displaying your results.
The puzzles were of the sort that probably seemed incredibly inspired
to the people writing to the game, but to the poor player they were so
vague as to be almost impossible to figure out without the hints.
B
E
G
I
N
S
P
O
I
L
E
R
(One of the puzzles requires the player to examine a sign in a room
then set the number on the clock to the same as the number of letters
in the words on the sign. What the...? And I was supposed to figure
that out? How...?)
E
N
D
S
P
O
I
L
E
R
Other times, the way the game's set up helps you with puzzles you might
otherwise not even be aware existed. I found a crowbar in one location
and then noticed somewhere else that an option opened up to use it. At
the time, it hadn't occurred to me to even try to use the crowbar in
that way... a clear indication that this format is never going to be as
good as any of the standard text adventure systems you'd care to name.
Overall the game seemed pretty much bug free and I didn't encounter any
error messages popping up on screen like with the other online game I
played recently. The main annoyance were the constant reminders
littered through the story of the wonders of the system used to create
the game, like "look at the amazing things you can do with this system!
Isn't it brilliant! Isn't it amazing!" Er... it's just about adequate
for getting the job done, but I'm sure a far more polished product
could have been created with any of the standard text adventure
systems. How this one is supposed to be superior I'm not sure, and I've
listed above some of the ways in which it's inferior.
The Escape is probably best viewed as a novelty item as opposed to a
serious game. While it's certainly playable, the system's flaws prevent
it ever being anything more.
4 out of 10
- - - - - - - - - - - - - - -
ESCAPE FROM ST. MARY'S, by Ryan Menezes
Platform: HTML
Play it online:
http://rinkworks.com/adventure/
Reviewed by David Whyld
This was one of only a few times I'd played a HTML game over the
internet (the recent IFComp being the first) and I'm still not
convinced it's a better idea than simply writing the same game in a
standard text adventure system. There's a noticeable lag even on a
broadband connection between clicking on an option and the screen
refreshing to display the next page of tag. The interface is kind of
okay. It's split down the middle, with the 'happening now text' (for
want of a better phrase) in a little box on the left hand side and the
room description on the right, with a list of clickable options
beneath. Takes a bit of getting used to but is simple enough once
you've been playing for a few minutes.
The aim of the game seems to be to get out of school (the St Mary's of
the title), although best of luck to anyone who has the patience to
figure out how to do this. Ten minutes into the game and I was still
stuck in the first location. Eventually I hit upon the solution, but as
this came after being hit first with several error message screens my
enthusiasm for the game was seriously beginning to wane.
Making progress is slow and frustrating. Clicking on the various
options takes you to different sets of options, most of them almost
identical to the previous set. There are constant errors popping up on
screen from time to time: trying to open or drink from the bottle
displays an error message page, as does clicking the 'nothing' option.
Strangely, click the same options on a different page and they work
fine. Then again, the whole system is frustrating. Clicking on an
inventory option brings up a list of other options for that item.
Clicking on some of them bring up still more options, while clicking
others take you back to the main menu and if you want to go back to the
item options again you need more clicking to get back there. Some of
the errors seemed to occur when I used the back button on my browser to
move back a screen to try a different option; others just seemed to
occur purely at random. A lot of persistence is required.
The game opens up and becomes more interesting once you're out of the
classroom with a fairly large number of locations to explore. There are
quite a few NPCs scattered around, although I wasn't able to interact
with the majority of them, and the few who deigned to speak to me
didn't tell me anything I found very helpful.
Overall I had mixed feelings about Escape From St Mary's. The system
was flawed due to the sheer number of error messages I kept
encountering, and the game itself, while reasonably well written, just
wasn't that interesting.
More of a novelty item than something I would recommend.
4 out of 10
To the reviewer, David Whyld:
I'm not the author of this game, but I'm a fellow developer for the
games hosted on RinkWorks, and I felt the need to reply here to clear
up a few points of confusion -- more about the game system we use than
about Ryan's game itself.
> This was one of only a few times I'd played a HTML game over the
> internet (the recent IFComp being the first) and I'm still not
> convinced it's a better idea than simply writing the same game in a
> standard text adventure system.
Just a small note here: the RinkWorks adventure games themselves aren't
designed using HTML. They're written in a specially designed language
called Smash, which is then interpreted by a server-side engine to
generate the HTML for the page presented to the player. I just bring
this up to make it clear that RinkWorks' games aren't of the usual sort
of web-based games which comprise navigation of mostly static HTML
pages.
> The aim of the game seems to be to get out of school (the St Mary's of
> the title), although best of luck to anyone who has the patience to
> figure out how to do this. Ten minutes into the game and I was still
> stuck in the first location. Eventually I hit upon the solution, but as
> this came after being hit first with several error message screens my
> enthusiasm for the game was seriously beginning to wane.
These were not bugs in the game code. I helped test the game in
December, and while there may well be very subtle bugs which can be
triggered in uncommon, complex situations later in the game, the error
messages described here were due to misuse of the browser (read on
below).
> Making progress is slow and frustrating. Clicking on the various
> options takes you to different sets of options, most of them almost
> identical to the previous set. There are constant errors popping up on
> screen from time to time: trying to open or drink from the bottle
> displays an error message page, as does clicking the 'nothing' option.
> Strangely, click the same options on a different page and they work
> fine. Then again, the whole system is frustrating. Clicking on an
> inventory option brings up a list of other options for that item.
> Clicking on some of them bring up still more options, while clicking
> others take you back to the main menu and if you want to go back to the
> item options again you need more clicking to get back there. Some of
> the errors seemed to occur when I used the back button on my browser to
> move back a screen to try a different option; others just seemed to
> occur purely at random. A lot of persistence is required.
The game system is designed to *not allow* the user to back up in the
browser (analagous to "undo" in parser-based games) and select
alternative options. This does not pose a problem with unwinnable
situations, since all RinkWorks Smash games are designed so that it's
impossible to reach an unwinnable state -- with the exception of a move
which kills you, from which you *can* and are *forced* to immediately
undo.
If you attempt to back up in your browser and select a move from an
"outdated" page, you'll get an error message alerting you to that fact.
Nevertheless, backing up in your browser is still useful, as you can
reread the text resulting from recent moves this way. From the way you
describe your experience, it sounds like all of these errors can be
attributed to misuse of backtracking in the browser.
> The game opens up and becomes more interesting once you're out of the
> classroom with a fairly large number of locations to explore. There are
> quite a few NPCs scattered around, although I wasn't able to interact
> with the majority of them, and the few who deigned to speak to me
> didn't tell me anything I found very helpful.
>
> Overall I had mixed feelings about Escape From St Mary's. The system
> was flawed due to the sheer number of error messages I kept
> encountering, and the game itself, while reasonably well written, just
> wasn't that interesting.
Certainly each reviewer is entitled to his opinions about his
game-playing experiences, so I've only tried to address the more
objective factual inaccuracies so far. Naturally nothing can be done
to guarantee a consistently quick experience for a web-based game, but
I'm still quite sure that your original impressions of "bugginess" kept
you from sticking with the game long enough to see its strengths.
Based on information from the game logs, you spent well under 200 moves
on the game, only 73 of which took place outside the first room --
barely enough to even *traverse* the game's geography, much less try
anything. I only bring this up to question whether the game was given
a fair shake (especially regarding the NPCs, which I'd dare say most
RinkWorks game players think are one of the great strengths of the
game, once you actually begin to work through the puzzles).
--Andrew Walters
> Based on information from the game logs, you spent well under 200 moves
> on the game, only 73 of which took place outside the first room --
> barely enough to even *traverse* the game's geography, much less try
> anything.
This, I think, is the strongest argument against playing your games. Not
only do you keep a log of players' moves, but you also use that log to
publicly discredit them when they critisize the game. Man, when I think of
all the stupid stuff I type when I get stuck or bored... The idea that some
disingenious game developer is watching over my shoulder, always ready to
make my log public, well, it just creeps me out.
I think you owe David an apology.
Note that this was written by a self-confessed troll. You needn't take
it seriously.
Greg
This is partly my fault, and I have changed the "Platform: HTML" part
on my web site, so that it now says "Platform: Smash."
This is valuable information for players to take into account after
reading David Whyld's review. However, I'm not sure I agree that his
complaints about errors are based on factual inaccuracies, since he or
anybody else could respond, "Yeah, I understand why this is happening,
but I still think the errors (or whatever they are) could have been
handled better," or else "Yeah, which is why a web browser is not the
best thing to play a game with," or whatever.
> Certainly each reviewer is entitled to his opinions about his
> game-playing experiences, so I've only tried to address the more
> objective factual inaccuracies so far. Naturally nothing can be done
> to guarantee a consistently quick experience for a web-based game, but
> I'm still quite sure that your original impressions of "bugginess" kept
> you from sticking with the game long enough to see its strengths.
>
> Based on information from the game logs, you spent well under 200 moves
> on the game, only 73 of which took place outside the first room --
> barely enough to even *traverse* the game's geography, much less try
> anything. I only bring this up to question whether the game was given
> a fair shake (especially regarding the NPCs, which I'd dare say most
> RinkWorks game players think are one of the great strengths of the
> game, once you actually begin to work through the puzzles).
Hmm. Part of me wants to say, "As far as I'm concerned, there's nothing
wrong with playing a game, not getting very far past the first puzzle,
looking at the rest of the game, deciding that what you see doesn't
interest you enough to want to play further, and then afterwards
telling people about it."
On the other hand, I can't deny that David Whyld's review would have
been better if he had played the entire game before reviewing it.
I guess I'll consider implementing a "play at least half the game"
policy for next year (if I do this next year). I've also added a link
on my web site to this discussion, so people can get a balanced view of
the game.
Greg
If it walks like a duck, quacks like a duck, then it's probably a
duck... But okay, it's Smash and not HTML, but otherwise is pretty much
indistinguishable from static HTML pages.
>
> The game system is designed to *not allow* the user to back up in the
> browser (analagous to "undo" in parser-based games) and select
> alternative options. This does not pose a problem with unwinnable
> situations, since all RinkWorks Smash games are designed so that it's
> impossible to reach an unwinnable state -- with the exception of a move
> which kills you, from which you *can* and are *forced* to immediately
> undo.
>
>
> If you attempt to back up in your browser and select a move from an
> "outdated" page, you'll get an error message alerting you to that fact.
> Nevertheless, backing up in your browser is still useful, as you can
> reread the text resulting from recent moves this way. From the way you
> describe your experience, it sounds like all of these errors can be
> attributed to misuse of backtracking in the browser.
I didn't actually make a point of noting exactly where the errors
occurred, so it's possible they all *did* occur because I was using the
back button on my browser to return to a previous page. But, might I
ask, why should this produce an error message? Why disable "undo"?
Disable it in a standard text adventure and you'll have people complain
about it, so disabling the same kind of principle here doesn't make me
any more inclined to like your game. Aside from anything else,
shouldn't it have told me this was why I was getting the error message?
Sorry, but when I run into a dozen or so errors, my initial thinking is
that "oh, the game's buggy" not "whoops, shouldn't have used the back
button on my browser". However you look at it, it's a flaw in the
system so I think I'll leave my review as it stands as far as the
'errors' are concerned.
BTW, what would happen if I opened each option in a different tab?
Would that allow me to bypass the disabled undo option as the previous
options would still be available in the previous tabs.
>
> Certainly each reviewer is entitled to his opinions about his
> game-playing experiences, so I've only tried to address the more
> objective factual inaccuracies so far. Naturally nothing can be done
> to guarantee a consistently quick experience for a web-based game, but
> I'm still quite sure that your original impressions of "bugginess" kept
> you from sticking with the game long enough to see its strengths.
>
> Based on information from the game logs, you spent well under 200 moves
> on the game, only 73 of which took place outside the first room --
> barely enough to even *traverse* the game's geography, much less try
> anything. I only bring this up to question whether the game was given
> a fair shake (especially regarding the NPCs, which I'd dare say most
> RinkWorks game players think are one of the great strengths of the
> game, once you actually begin to work through the puzzles).
>
I'd have said it was more than 200 moves personally, although I never
bothered keeping track at the time. My review *was* a little rushed,
admittedly, as I was playing the game to a very tight deadline, but I'm
not sure I really would have played for much longer anyway, time
allowing. The basic premise of the game - escaping from your school -
just isn't that interesting, and the errors (whether you accept them
for what they were or not) were annoying and probably contributed a lot
towards my deciding "enough was enough".
>> If you attempt to back up in your browser and select a move from an
>> "outdated" page, you'll get an error message alerting you to that fact.
>> Nevertheless, backing up in your browser is still useful, as you can
>> reread the text resulting from recent moves this way. From the way you
>> describe your experience, it sounds like all of these errors can be
>> attributed to misuse of backtracking in the browser.
>
> I didn't actually make a point of noting exactly where the errors
> occurred, so it's possible they all *did* occur because I was using the
> back button on my browser to return to a previous page. But, might I
> ask, why should this produce an error message? Why disable "undo"?
I almost always disable the "back" button in my games. Well, I don't disable
it per se, I just add a history.forward() on every page. In order to allow
"back" to work as an undo, the game would need to remember the complete
world state for every possible turn (or at least the prior turn(s) allowed
for undo), and then use a state tag embedded on each version of the page.
Stand-alone interpreters apparently do this ('terp authors would have no way
of knowing what is or isn't important, so the entire data state is
remembered). I guess it wouldn't be a lot harder to do this in server code,
but if the engine wasn't designed that way, then backing up using "back" and
then re-submitting would be catastrophic. Hence, the "back" button has to be
disabled.
I think there is a big misconception between web pages, where "back" makes
sense, and web applications, where it might not. In web IF, the author would
either need to do as I describe earlier, or provide a custom "back" option.
When you see the back button working in web applications, it's usually not
trivial. A lot of effort was probably put into state maintenance, and
special-purpose web aps can handle this however they like (breadcrumbs,
saving important variables with a state ID, whatever).
If anything, the game in question can be faulted for not including an "undo"
option. I'm in the camp that thinks it's unfair to expect the "back" button
to *be* the undo option, although if it is, all the better.
> Disable it in a standard text adventure and you'll have people complain
> about it, so disabling the same kind of principle here doesn't make me
> any more inclined to like your game. Aside from anything else,
It seems to me that "back" was disabled, and "undo" was not included. Not
the same thing.
> shouldn't it have told me this was why I was getting the error message?
> Sorry, but when I run into a dozen or so errors, my initial thinking is
> that "oh, the game's buggy" not "whoops, shouldn't have used the back
> button on my browser". However you look at it, it's a flaw in the
> system so I think I'll leave my review as it stands as far as the
> 'errors' are concerned.
I'll have to try this game. It seems that there could have been a better
solution.
> BTW, what would happen if I opened each option in a different tab?
> Would that allow me to bypass the disabled undo option as the previous
> options would still be available in the previous tabs.
If the game isn't remembering every aspect of the prior state, then it's
hopefully at least remembering a "current state" code. Re-submitting an
outdated page shouldn't work. If it does, then they have more design issues
than I would expect. My guess is, you'd get the exact same error(s), since
it already knows you went "back" and submitted an old page.
> I'd have said it was more than 200 moves personally, although I never
> bothered keeping track at the time. My review *was* a little rushed,
> admittedly, as I was playing the game to a very tight deadline, but I'm
> not sure I really would have played for much longer anyway, time
> allowing. The basic premise of the game - escaping from your school -
> just isn't that interesting, and the errors (whether you accept them
> for what they were or not) were annoying and probably contributed a lot
> towards my deciding "enough was enough".
I haven't read the review, but I'd call it very fair if you said the review
was based on impressions taken from the beginning portions of the game, and
that the errors/problems kept you from getting much farther. Hopefully, that
was mentioned. :)
---- Mike.
Addressing each point in turn:
(1) This is a stylistic call between platforms that you're perfectly
free to like or dislike, inside or outside a review, of course.
However, the game is explicitly designed so that you can never
reach an unwinnable state, and except for a couple of easter
eggs, you really can't do much of anything that cuts off alternate
avenues from you. There is, therefore, not much if any *need* for
an "undo," because no matter what you do, you can always just
pursue an alternate path without undoing what you've already done.
(2) Technically, you are correct -- the error message should have
explicitly cited your use of the browser's back button as a problem.
That said:
- That error message came from the Smash engine/interpreter, not
the game, so technically speaking that observation belongs in a
review of the platform rather than the game itself. A passing comment
in a review of the game might be appropriate but not as almost the
whole review.
- The "Adventure Games Live" site, which has hosted games with
the same engine, same interface, and same back-button error
message has been active since 1998. 34,000 distinct players have
registered for it and played the games on there in the last two years
alone. I get email about the site daily, and my Hints Board -- a
message forum on my site -- has been getting dozens of posts
about Escape From St. Mary's every day since its release. And you
are the ONLY PERSON who hasn't been able to figure out the
browser interface. I don't know why. Because of your confusion, I
will be changing the error message text to mention the back button
explicitly, but for the time being, I think it's safe to say that your
confusion on the matter is personal enough that labelling it a fault
of the game's interface is unreasonable.
> If it walks like a duck, quacks like a duck, then it's probably a
> duck... But okay, it's Smash and not HTML, but otherwise is pretty
> much indistinguishable from static HTML pages.
This is, frankly, only a conclusion someone who hasn't played very far
could make. There are 76 of items in the game, and virtually all of
the 70+ locations have multiple states with distinct area descriptions.
If it was all static HTML pages, there would have to be one static page
for every possible combination of the dozens of inventory items,
times every location, times every state that location can be in, times
the number of distinct action responses you can receive. That's
*billions* of distinct combinations. Smash is as much like static HTML
as a game that runs in a standard 80x24 terminal window is like a
linked archive of all possible 80x24 terminal displays.
> I'd have said it was more than 200 moves personally, although I never
> bothered keeping track at the time. My review *was* a little rushed,
> admittedly, as I was playing the game to a very tight deadline, but I'm
> not sure I really would have played for much longer anyway, time
> allowing. The basic premise of the game - escaping from your school -
> just isn't that interesting, and the errors (whether you accept them
> for what they were or not) were annoying and probably contributed a lot
> towards my deciding "enough was enough".
The errors you received certainly explain why you quit, but is the
review a fair one? The Review Project guideline stated this as one
of the clauses:
"It's always better if you can finish a game before reviewing it,
although I am not fussy about this. If you've played a game enough
to get a feel for it, and if you've tried to finish but haven't
succeeded, that's probably good enough for the NCRP. So much the
more if it's a hard game to finish, and if you've played at least
half of it."
You did not breach this guideline by any objective standard,
because there isn't one, but you most certainly did not play the
game enough to get a feel for it, as evidence by your statement
that the game's premise is about "escaping from school." Yes,
this is the motivation that starts you off, but as you find out in
just the initial survey of the game's geography (had you even
played that far) you would find out that actually the game's
subplots are the real meat of it and involve doing undercover
investigative work for a government agent, experimenting with
time travelling, dealing with cannibals, power struggles, kung
fu fights, computer viruses, and numerous other archetypal staples
of boyish fantasies.
Whether this sounds more interesting to you or not, you did not
play long enough to encounter any of these things, and, therefore,
your review is not based on having a "feel for it."
How far did you get? 155 moves, as Andrew previously mentioned.
Only half of them took place after the first puzzle, once you have the
freedom to move about. That's not even enough to visit all the
geography you can freely access after the first puzzle, let alone
enough to actually do things in them.
The Hall of Fame for the game -- located at
http://www.rinkworks.com/adventure/hall.cgi?game=stmarys -- lists
everybody who has completed the game to date. As you can see, multiple
people finish it each day, and the average number of moves it takes to
complete the game (the first time through, that is) ranges from 4000 to
8000 moves. At 155 moves, you completed 2.5% of the game at the most;
less than that in terms of puzzles solved,
which was the initial puzzle only.
Greg,
I fully acknowledge that a review that says, "I started this, got
frustrated, and wanted to quit" is a helpful thing for prospective
players to know. It's a valid perspective. But what about, "I
started this, got frustrated, and wanted to quit. But after sticking
with it a while, I managed to figure out the interface, and gradually
the game grew on me."? Even "I started this, got frustrated, and
wanted to quit. After sticking with it long enough to get a feel for
the game, I discovered my initial instincts were right" would fair
and give me no cause for complaint.
Consider a book or movie review by a reviewer who only experienced
2-3% of the book or movie. If Roger Ebert reviewed movies by watching
only the first 2-3% of each (about 2-3 minutes for most movies), there
would be an outrage. If the New York Times reviewed books based on
the first 5-10 pages, there would be a scandal. Games do take a
greater time commitment to play, so I fully sympathize and agree
with laxer standards with regard to reviewers completing games. But
I would suggest that Mr. Whyld's review of "Escape From St. Mary's"
is based on such an infinitesimal fraction of the game that the
review is blatantly unfair and mirepresentative. On these grounds,
I respectfully request the review be replaced (or, at least,
supplemented with a second review by another person). Just to
reiterate, my issue is not with a negative review -- simply with
an unfair review.
Whether you agree to this or not, I appreciate your willingness to
listen and discuss the matter, both here and in our emails. Thanks.
-- Sam.
This is exactly correct. The Smash engine remembers, on the server
side, what the current state of the game is. If you submit an old
page, whether you used the back button, or you opened multiple
moves in different tabs, you'll get an error message that says,
"Whoops. You're trying to make a move in the game using an
outdated page. To continue playing, you need to get back to where
you left off. Press the button below to do that." When you press the
button below, you get thrown back at the most recent page.
> (2) Technically, you are correct -- the error message should have
> explicitly cited your use of the browser's back button as a problem.
> That said:
A suggestion; I do this in my online games, and (unless I've forgotten),
nobody has ever complained. I don't think most people even stop to realize
that the game isn't *letting* them go backward.
Open the game in a chromeless window. No address bar, no back button,
nothing but the game. Add simple javascript to disable right-click (prevents
the pop-up "back" from working), and then put history.forward(); in
javascript on every result page. Pretty much, a person would have to try
*really really* hard to go back to a previous page. If they do, and they
submit it, the engine already knows how to reject it.
And then add an "undo" option. Players don't necessarily know/care that they
can or can't get stuck, but it sure is nice being able to look at the
results to different courses of action. Perhaps you say "Yes" to Bob.
Perhaps you say "No". Especially when it comes to review time, playing a
couple moves on each branch helps. Yeah, it doesn't exactly fit in with
traditional gaming, but IF players are a spoiled lot. :)
> - That error message came from the Smash engine/interpreter, not
> the game, so technically speaking that observation belongs in a
> review of the platform rather than the game itself. A passing comment
> in a review of the game might be appropriate but not as almost the
> whole review.
I wouldn't have known the difference between the Smash engine and the game
itself. Most browser-based IF I've seen blends the engine and the game
together. Smash differs, and in recent days we've seen another example or
two of this. I even have a friend who's working on a browser-based IF IDE.
The tendency remains, though, to consider the game and the engine one
entity, but that'll change as these things become more commonly used.
---- Mike.
You're remembering the game state somehow, for this to work. Would it be
possible (just speculating) to add an option on the error page that brings
the user back to the current state? It could be as simple as saving the
output from the most recent page, and then re-displaying it whenever the
user jumps back in time. It doesn't solve the absence of an "undo", but it
would at least keep people out of trouble if they did get into this
situation.
--- Mike.
Unless I misunderstand, this is actually exactly what happens.
When you get the error, you get a button (the one mentioned
in the above quoted error text). Press it, and you are instantly
transported to the most recent page. Is this what you mean?
>> You're remembering the game state somehow, for this to work. Would it be
>> possible (just speculating) to add an option on the error page that
>> brings
>> the user back to the current state? It could be as simple as saving the
>> output from the most recent page, and then re-displaying it whenever the
>> user jumps back in time. It doesn't solve the absence of an "undo", but
>> it
>> would at least keep people out of trouble if they did get into this
>> situation.
>
> Unless I misunderstand, this is actually exactly what happens.
> When you get the error, you get a button (the one mentioned
> in the above quoted error text). Press it, and you are instantly
> transported to the most recent page. Is this what you mean?
Yep. You can tell, I'm just responding from the other feedback. I went to
the site, but didn't yet try the games.
The way it was discussed, I thought the error was a game-killer. Like, you
hit "back", pick a different option, and get an error and then you're
doomed. No way to go forward, because your browser has killed the prior
history and you're on a different branch. But if you can get back to the
most recent page, then I'd probably catch on after doing it a time or two.
Maybe the error looks to scarry? Again, I haven't seen it. Maybe it should
say that "undo" is not available at this time, since that's probably why
it's used.
I still like the idea of opening with no chrome, and putting
history.forward() on every page. I don't know how many thousands of players
have gone through my main game in the past seven years, but the technique
has always worked fine.
--- Mike.
You could argue that there's no *need* for an UNDO command in 99% of
regular IF, but do you think people would appreciate 99% of the games
they play not recognising the command?
> - That error message came from the Smash engine/interpreter, not
> the game, so technically speaking that observation belongs in a
> review of the platform rather than the game itself.
And having never used Smash or played the game before, I'm supposed to
have been aware of that?
> - The "Adventure Games Live" site, which has hosted games with
> the same engine, same interface, and same back-button error
> message has been active since 1998.
It's been running for 8 years with this error message in place and you
haven't done anything about it?
> And you
> are the ONLY PERSON who hasn't been able to figure out the
> browser interface.
I *do* mention in my review that I guessed some of the errors were as a
result of me using the back button.
> Whether this sounds more interesting to you or not, you did not
> play long enough to encounter any of these things, and, therefore,
> your review is not based on having a "feel for it."
My review was based on my "feel for it" for the time I spent playing
it. And my opinion of the game was that it wasn't anything particularly
special. If I hadn't been intending to review it, I'd have quit in the
first location and not given it a second thought. I certainly would
have quit when coming across my fifth or sixth error message screen.
Why would I do anything about something that has
_never_been_a_problem_ in all those 8 years?
It's not a bug in my code -- it's what I purposefully
intended to occur to when people try to use the back button.
For every *other* one of my 34000 registered users, this was
an intuitive, cleanish way to handle it.
Now you've come along and encountered a usability issue with
it, and I've already said I'll "do something about it" by, at minimum,
changing the error message to explicitly mention the back button.
> I certainly would have quit when coming across my fifth or sixth
> error message screen.
As far as I can tell, you're pretty much the only person to have even
*gotten* to five or six error screens before they figure out what
the error message actually means.
--
Mike, your suggestion about disabling the back button entirely is
a good one. Stylistically, I'm not sure I like spawning a new browser
window, as that's not really in keeping with the way the rest of my
site works and, if historical performance is an indicator of future
returns, would only solve one person's technical issues every eight
years. Still, it's an idea I will take into consideration and probably
experiment with, at the very least. Thanks very much.
> Mike, your suggestion about disabling the back button entirely is
> a good one. Stylistically, I'm not sure I like spawning a new browser
> window, as that's not really in keeping with the way the rest of my
> site works and, if historical performance is an indicator of future
> returns, would only solve one person's technical issues every eight
> years. Still, it's an idea I will take into consideration and probably
> experiment with, at the very least. Thanks very much.
As a test, you could try a version that just does history.forward(); on each
game page, even if you don't open a new window. It might be less intuitive,
since it will *appear* that the back button simply isn't working, but then
it avoids the error entirely. No matter how many pages backward they manage
to get, it'll quickly flip all the way forward again. If they somehow did
get around it, your current state checking does the trick. The trick has
worked well for me.
Maybe put something on the intro page that says the games do not use "back"
as an undo feature, too. Again, if you already have it, I plead ignorance.
One thing I have found, though, is that just because nobody complains, it
doesn't mean nobody has encountered the same problem. If somebody only
played 10 moves, that might be why. Unless they're writing a review, chances
are you might never get that feedback at all. :)
---- Mike.
On my way home, I was reflecting on this thread, and I remembered
the other reason I've left the behavior the way it is now. When
playing, sometimes it is exceptionally useful to be able to go back
and *view* prior moves. Sometimes you realize you misread the
text one move too late, or you might just want to reread something.
The way things are now, it's easy to go back and review prior
moves, then jump forward again and continue. If you forget to jump
forward, the intention is that the error message alerts you to this
fact, and then you smack a button, get the current page, and
continue on your merry way.
> One thing I have found, though, is that just because nobody complains, it
> doesn't mean nobody has encountered the same problem. If somebody only
> played 10 moves, that might be why. Unless they're writing a review, chances
> are you might never get that feedback at all. :)
That's true, and it's definitely possible someone else has had this
confusion and not said anything. But I do get daily feedback on the
site, both good and bad, both from veterans and first-timers, and
the games have an active message board where people usually
just ask for hints but also discuss technical issues. I really think
that if this issue was a problem for a significant number of people,
I'd have heard about it at least once before now.
I suspect part of it is the expectations this group in
rec.games.int-fiction
have about IF games. Until now, my audience has been either
newcomers to the genre, or players who thrived on the text
adventures from the 80s and fell out of the habit. Neither would
expect a universal "undo" feature, and so neither would be looking
for one. Now that my site is suddenly in full view of the hardcore
folks here in this group, who have become accustomed to "undo"
functionality over the last decade, it's possible that more people
will be trying to use the back button as an "undo," and if only
a tenth of a percent of those are unable to figure out how to
interpret the resulting error message, that's still more people with
that problem than in the past.
I still think the error message is crystal clear about what it actually
means, but to address Mr. Whyld's confusion and the possibility
of anyone else having that same confusion, I've just now enhanced
the wording of the error message so that it now references the
"back" button explicitly. It's a good thought to talk about this
in the site's instructions, too; thanks for the idea.
I decided to play Escape From St. Mary's.
Other than the fact that Whyld didn't realize how he was causing the
error pages, I think his review was fair.
It takes (me) nearly three seconds to get a response to clicking
something. This makes it very frustrating to get responses that are
variations of "you don't really want to do that." (For example:
Talking to either classmate NPC, offering the teacher a cookie
just to be told you don't have one, throwing the bottle
when it's closed, trying to get back into class when the game
has criticized you for not bringing your backpack with.
A bit later, I tried a conversation topic offered for an NPC,
to be told that I "feel too involved now to go chatting about the
subject to everyone you meet.")
If the option was nested in an inventory menu, you've got
to open the menu up again. If I didn't know better I would
try to click "Back" as well, since it's faster.
The first puzzle is definitely frustrating. You have to attempt
a seemingly futile action more than once in order to cause
a previously useless "examine" to reveal an item. When I
first got this item I didn't realize what I had done to make it
available. I was guessing (fortunately incorrectly) that I'd
done it simply by exhausting the selection of unhelpful options.
Kevin Venzke
> I didn't actually make a point of noting exactly where the errors
> occurred, so it's possible they all *did* occur because I was using the
> back button on my browser to return to a previous page. But, might I
> ask, why should this produce an error message? Why disable "undo"?
> Disable it in a standard text adventure and you'll have people complain
> about it, so disabling the same kind of principle here doesn't make me
> any more inclined to like your game. Aside from anything else,
> shouldn't it have told me this was why I was getting the error message?
I would suggest that anyone looking into browser-based IF should
seriously investigate AJAX technology. One of the complaints about AJAX
is that the back button no longer works; in this case that might be an
advantage.
Can I ask what kind of Internet connection you have? The delay I
normally experience is a quarter second at most. I realize some
people on dial-up or other laggy connections are not going to
experience this fast a turnaround, and I can certainly sympathize
with anyone making this criticism.
> The first puzzle is definitely frustrating.
This, too, is a fair comment for a review -- but also not a fair
basis for a review. The first puzzle is only a quickie puzzle
to introduce the player to the inventory manipulation scheme.
To base a review on it is akin to basing a book review on the first
chapter, or a movie review on the first scene. If book and movie
critics are expected to invest two hours or more researching their
reviews by reading the book or watching the movie they're
reviewing, I think it is only fair to expect game reviewers to spend
at least that long playing the games they're reviewing, given that
games are normally even longer forms of entertainment. Even if
you have unusual trouble solving the first puzzle, it doesn't take
more than ten minutes at the outside.
> I decided to play Escape From St. Mary's.
I decided to play "Trainer", which is billed as an introduction to the
site and, I presume, the gaming system.
> It takes (me) nearly three seconds to get a response to clicking
> something.
It took a couple of seconds for the page to completely refresh after
each "OK" click, but it wasn't anything that I haven't seen on other web
sites. Now that I've seen everything, I strongly want to see an AJAX
interface. Only refreshing portions of the page both is faster and
seems faster yet, since you aren't watching portions of the page refresh
that you aren't interested in.
> If the option was nested in an inventory menu, you've got
> to open the menu up again. If I didn't know better I would
> try to click "Back" as well, since it's faster.
The mechanics of the interface were a bit frustrating for me as well. I
would have liked a way to impose different CSS style-sheets on the page;
instead I had a single button that toggled the appearance of the
checkboxes. Rather than two side-by-side windows that change their
width, I'd prefer a vertical arrangement, with the room description on top.
> The first puzzle is definitely frustrating. You have to attempt
> a seemingly futile action more than once in order to cause
> a previously useless "examine" to reveal an item. When I
> first got this item I didn't realize what I had done to make it
> available. I was guessing (fortunately incorrectly) that I'd
> done it simply by exhausting the selection of unhelpful options.
The training game has similar puzzles, but I'm not too upset about it.
Several games require you to do the same action multiple times before
you get the results that you want, although it is usually in the context
of NPC conversations.
I'm on a 2 MB connection and that's pretty much the delay I
experienced. So most of my time spent playing the game was waiting for
the screen to refresh itself, which doesn't make for a very exciting
game playing experience. I got used to delays like this when I was on
dialup modem but when you pay for a 2 MB connection you expect things
to be lightning fast.
>
> > The first puzzle is definitely frustrating.
>
> This, too, is a fair comment for a review -- but also not a fair
> basis for a review. The first puzzle is only a quickie puzzle
> to introduce the player to the inventory manipulation scheme.
> To base a review on it is akin to basing a book review on the first
> chapter, or a movie review on the first scene. If book and movie
> critics are expected to invest two hours or more researching their
> reviews by reading the book or watching the movie they're
> reviewing, I think it is only fair to expect game reviewers to spend
> at least that long playing the games they're reviewing, given that
> games are normally even longer forms of entertainment. Even if
> you have unusual trouble solving the first puzzle, it doesn't take
> more than ten minutes at the outside.
Starting any game with a puzzle like that is never a good idea. I *did*
come pretty close to quitting in annoyance, and in the end I think I
only hit upon the correct solution by sheer persistence, i.e. I'd tried
every other available action so sooner or later I was bound to hit upon
the correct one by pure dumb luck if nothing else. There didn't seem to
be any kind of logic to the puzzle solving either. I clicked an option,
nothing special happened, later on I clicked the same option again and
this time something happened. That's hardly my idea of a fair puzzle.
It's DSL. It says I'm connected at "100 Mbps."
> and I can certainly sympathize
> with anyone making this criticism.
I'm not complaining about the response time in itself. It's the
response time together with the game offering numerous options
which, apparently, never do anything interesting, and are often
rejected for the reason that I the player character don't actually
want to use that option.
I'd suggest that anyone writing games with this system should
imagine that the player is at an arcade and has to pay a
dollar for every ten clicks or something.
>> The first puzzle is definitely frustrating.
>
> This, too, is a fair comment for a review -- but also not a fair
> basis for a review. The first puzzle is only a quickie puzzle
> to introduce the player to the inventory manipulation scheme.
By "first puzzle" I'm not talking about figuring out what to do
with the first item; I'm talking about making that item available
to begin with. The first time I played, I was at such a loss over
this (I read the hint for this part) that I started wondering if I
was missing some key part of the interface.
> To base a review on it is akin to basing a book review on the first
> chapter, or a movie review on the first scene. If book and movie
> critics are expected to invest two hours or more researching their
> reviews by reading the book or watching the movie they're
> reviewing, I think it is only fair to expect game reviewers to spend
> at least that long playing the games they're reviewing, given that
> games are normally even longer forms of entertainment. Even if
> you have unusual trouble solving the first puzzle, it doesn't take
> more than ten minutes at the outside.
Movie and book critics can't write reviews based on a partial
experience, because such reviews wouldn't be competitive.
There are enough people out there willing to experience the
whole work before writing. Nobody would read (for information
purposes) a critic who regularly shuts the movie off after 30 min.
I'm guessing there is a shortage of reviews for this game.
Maybe you could ask the site's members to write reviews.
Kevin Venzke
> Movie and book critics can't write reviews based on a partial
> experience, because such reviews wouldn't be competitive.
> There are enough people out there willing to experience the
> whole work before writing. Nobody would read (for information
> purposes) a critic who regularly shuts the movie off after 30 min.
A bigger issue is that films and books don't really have anything that
corresponds to bugs or bad interface. In other words, you can't "get stuck"
watching a boring movie. A movie critic can be expected to sit through a
film, even if it sucks dead rats through a straw.
> A bigger issue is that films and books don't really have anything that
> corresponds to bugs or bad interface. In other words, you can't "get stuck"
> watching a boring movie. A movie critic can be expected to sit through a
> film, even if it sucks dead rats through a straw.
Wow, I agree with both of Pudlo's posts in this thread.
And from my experience on rinkworks.com a few years ago (you can
check the logs, I suppose), it is my unfair but honest opinion that
the reviewers gave the site more time than it deserves.
Stephen.
Kevin Venzke wrote:
> I'm not complaining about the response time in itself. It's the
> response time together with the game offering numerous options
> which, apparently, never do anything interesting, and are often
> rejected for the reason that I the player character don't actually
> want to use that option.
While I can see the validity of this point of view, I am somewhat
curious about the context of the complaint. As I read this thread, I
assume that most people here are comparing Escape from St. Mary's (ESM)
to traditional IF games; however, if this is the case, it seems to me
that it is illogical to complain about the fact that ESM offers options
which apparantly do nothing. My experience with traditional IF (which
is admittedly somewhat limited in the past five years) has led me to
believe that IF games can't help but be full of options which
apparently do nothing; this is inherent to the concept of having
interpreted strings used for commands. ESM (and other Adventure Games
Live (AGL) games) tend to provide options that do nothing but add
flavour and context, simply to broaden the number of available options
in the game and prevent the game from being reduced to a linear
experience of clicking the few options that advance the plot.
When I started playing the AGL games in 2000, I basically stopped
looking at other forms of IF. One of the biggest reasons for this was
the knowledge that when playing AGL, I could see at all times what my
options were. Sometimes some of those options apparently do nothing;
however, in traditional IF, there are usually many more options that
also do nothing, and I found THAT to be more time-consuming and
frustrating.
> I'd suggest that anyone writing games with this system should
> imagine that the player is at an arcade and has to pay a
> dollar for every ten clicks or something.
I'm afraid I don't understand the reasoning for this suggestion. Are
you suggesting that the games should reduce or eliminate the
trial-and-error aspects of puzzle solving? Please accept my apologies
if this was not your intended meaning.
> >> The first puzzle is definitely frustrating.
> >
> > This, too, is a fair comment for a review -- but also not a fair
> > basis for a review. The first puzzle is only a quickie puzzle
> > to introduce the player to the inventory manipulation scheme.
>
> By "first puzzle" I'm not talking about figuring out what to do
> with the first item; I'm talking about making that item available
> to begin with. The first time I played, I was at such a loss over
> this (I read the hint for this part) that I started wondering if I
> was missing some key part of the interface.
Having just played through this section of the game, I can certainly
see how this could have been problematic. I think one of the
difficulties encountered by the traditional IF players who are
contributing to this thread is the transitional logic in making the
jump from an interpreted command line to a menu-based option system.
Long-time players of AGL such as myself know that one of the simplest
puzzles that can be implemented in a menu-based system is to require
the repeated use of a single option. In traditional IF, the puzzle
might be deciding to try the specific option; in AGL, this approach
would trivialize things and so repetition is accepted as a reasonable
solution on occasion. Are there better types of puzzles available?
Absolutely. And those are much more common throughout the published
AGL games. The fact that a repetition puzzle is key to the opening
sequence of ESM is obviously a stumbling block to someone coming from a
traditional IF background, though, and it is unfortunate that this
stumbling block seems to be preventing contributors here from moving
forward to experience the rich depth of the rest of the game.
> I'm guessing there is a shortage of reviews for this game.
> Maybe you could ask the site's members to write reviews.
This sounds like an excellent idea, and in fact, it would probably have
already happened if not for the fact that most members of the Rinkworks
community do not have an audience outside of the community for which to
write reviews, and the reviews would serve little purpose within the
community. Now that you have mentioned it, though, perhaps some of our
regulars will step forward to write some reviews.
> It takes (me) nearly three seconds to get a response to clicking
> something.
This still confuses me a great deal. I have a subscription at
Rinkworks, which allows me to play the games without loading the ads;
this gives me page loads taking less than half a second. Even when I
log out of my subscription and load the ads, page loads are still well
under a second for me, and my understanding has been that this is
typical for most players of the AGL games, with most having typical
broadband (DSL or cable or equivalent) connections. The frustration
resulting from these delays is certainly understandable, but the
existence of these delays for those posting here while the regulars at
Rinkworks never encounter them is befuddling.
> You could argue that there's no *need* for an UNDO command in 99% of
> regular IF, but do you think people would appreciate 99% of the games
> they play not recognising the command?
Perhaps this is a difference in playing style preference. I have
always liked the fact that the AGL games do not need or allow players
to be able to undo actions. The fact that none of the AGL games can
ever get to an unwinnable state is not only an impressive feat of
design, but also an encouraging feature; when I play an AGL game, I
know that no matter how difficult it may be to solve the next puzzle, I
always CAN solve it, and I don't need to worry that the item that was
stolen from me five hundred turns ago has made all my subsequent
efforts futile. If I had the choice between a traditional IF game
where I have an UNDO command but can put myself in a position where I
may have to start the game over, and an AGL game where I can't UNDO but
can play knowing that I am not wasting my time, then I will (and have)
choose the AGL game without a second thought.
Furthermore, having played all of the AGL games to completion (except
for ESM, which I will get to soon enough), I can't say that I have ever
wanted an UNDO feature. I've played games that have had the
capability, and I don't miss it.
---
I would encourage those reading this discussion to try some of the
other AGL games as well -- a discussion of only ESM (the newest game,
including some game mechanics not available when the older games were
written) and The Trainer (an extremely simple introductory game) does
not provide a truly representative sample of the games in the
collection.
Donald Jackson
Just thought you might want to know.
Donald Jackson
Okay, thanks for that. It's fixed now.
> I don't know if this is the place for it (and I apologize if it isn't)
Well, maybe email me next time. *Shrug*
Greg
Me too! I find this discussion rather interesting, because I'm an avid
fan of both Rinkworks games and command-line IF games. In fact, it was
AGL that first got me hooked into adventure games a few years ago and
it was only when I exhausted Rinkwork's supply that I discovered this
lively community (being too young to have experienced the 1980s golden
age). I guess I'm biased because I feel a personal fondness and
nostalgia for the games, in much the same way that I would imagine
people here feel about Infocom, but I'll still weigh in with a defense
of the games.
When I started playing AGL, I didn't experience many of the
difficulties that have been mentioned here. I think a lot of it had to
do with the fact that I didn't approach it with the expectations of a
seasoned IF player. For example, I had no problem with the fact that
you couldn't "undo" an action in the same way in which you could in IF,
because the design of the games made it unnecessary to have to undo,
except when you made a fatal move. The games are, as others have
mentioned, impossible to put into an unwinnable state. The result is
that I was much more "adventurous" than I would have been in a
traditional IF game--trying out every option, no matter how ridiculous.
I found this overall design aim and the menu-based system really
helpful and gentle for a beginner who would have been much more
confused as to what to do with a command-line prompt.
Despite that, I can see the validity of many of the criticisms being
made about it. AGL is annoying because you have to wait for the page to
load each time you choose an option, and having numerous choices
presented to you that actually do nothing will be frustrating. The
trial and error that you have to go through for a lot of the puzzles
can be really very tedious. I also agree that the first puzzle in
Escape from St. Mary's was not very well clued, given my current
experience of other excellent command-line IF games. Escape isn't
really my favourite game in the Rinkworks emporium, I have to say.
The main reason why I still get excited about a new rinkworks game is
that I find them, on the whole, competently designed and fun to play.
Some of the games are worth it simply because the writing is really
funny. I'd personally recommend Fantasy Quest 1 & 2, which are still
the best spoofs of the fantasy game genre that I've played. The
consolation for options that "simply do nothing" is that they are
usually met with a hilariously sarcastic response.
Anyway, none of this is meant to dismiss people who didn't like the
games--just a rumination on why I like them. Overall, I just think that
traditional IF and AGL are two different ways of playing IF, both with
their own advantages and disadvantages. Even with its disadvantages,
AGL still gets IF out to a broader audience, and will hopefully make
new recruits search for more.
Half the game measured in what? Rooms? Puzzles? Text? How will the
reviewer know that he's played half the game?
Think before you write.
It could depend on when he's playing. If the site is busy, or if the
Atlantic link is busy, he'll get worse times.
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
One difference is that in traditional IF, I get the unhelpful response
as soon as I hit enter. In ESM I have to wait for it, which seems
to make it more disappointing when it happens.
There's also a major difference in how I decide what to try.
In traditional IF, I can usually assume that a necessary command
is going to use one of maybe 20 verbs, and nouns that can be
found in the game text only. That way, OFFER TEACHER A
COOKIE never has to be attempted unless the author is crazy
(there's no cookie in the game text).
When all the options are listed for me, I can't assume that
any of them are foolish to try, or unfair to require. When I select
an action and the game denies that I want to do it, this feels to
me like underimplementation. Traditional IF, too, can deny
that I want to do something that I typed, but *usually* I don't
feel like I was tricked into trying it.
> When I started playing the AGL games in 2000, I basically stopped
> looking at other forms of IF. One of the biggest reasons for this was
> the knowledge that when playing AGL, I could see at all times what my
> options were. Sometimes some of those options apparently do nothing;
> however, in traditional IF, there are usually many more options that
> also do nothing, and I found THAT to be more time-consuming and
> frustrating.
I can understand that. But I think that stripping out the player's
need to discover what the useful options are is too expensive.
I think it's a large part of what makes IF effective as a game and
an experience.
>> I'd suggest that anyone writing games with this system should
>> imagine that the player is at an arcade and has to pay a
>> dollar for every ten clicks or something.
>
> I'm afraid I don't understand the reasoning for this suggestion. Are
> you suggesting that the games should reduce or eliminate the
> trial-and-error aspects of puzzle solving? Please accept my apologies
> if this was not your intended meaning.
Not directly. I'm talking about response time again. Waiting for
responses is not so different from paying for them. If the author
imagines that everybody is paying per click, things will probably
come out better for players with slower response times.
I don't mind trial-and-error in theory, but I wonder what
you're referring to by this. Is offering the teacher a cookie, to
learn that I don't have one, an example of "trial-and-error" to
you? For me, this isn't a desirable kind of trial-and-error,
because no intelligence is used/needed to select the "trials."
It's just pushing all the buttons until something happens.
>> By "first puzzle" I'm not talking about figuring out what to do
>> with the first item; I'm talking about making that item available
>> to begin with. The first time I played, I was at such a loss over
>> this (I read the hint for this part) that I started wondering if I
>> was missing some key part of the interface.
>
> Having just played through this section of the game, I can certainly
> see how this could have been problematic. I think one of the
> difficulties encountered by the traditional IF players who are
> contributing to this thread is the transitional logic in making the
> jump from an interpreted command line to a menu-based option system.
> Long-time players of AGL such as myself know that one of the simplest
> puzzles that can be implemented in a menu-based system is to require
> the repeated use of a single option. In traditional IF, the puzzle
> might be deciding to try the specific option; in AGL, this approach
> would trivialize things and so repetition is accepted as a reasonable
> solution on occasion.
Ok. I can accept repetition as a puzzle solution for this type of game.
But certain things in ESM make me inclined to believe that this
won't be a solution. For instance, I believe standing up in class
always produces the same text of the teacher scolding you. I just
assumed that opening the window was the same situation.
> Furthermore, having played all of the AGL games to completion (except
> for ESM, which I will get to soon enough), I can't say that I have ever
> wanted an UNDO feature. I've played games that have had the
> capability, and I don't miss it.
I wanted UNDO when I left the classroom without the backpack
and the game criticized me for it. Playing again, it turns out that you
can't (as far as I can tell) actually take the backpack with you, but
the game criticizes you then anyway.
Even if you can't get ESM into an unwinnable situation, you can
still close off possibilities that you might have been able to see if
you had progressed more slowly. Offering the teacher a cookie
is an example: You don't have to do it, and once you're out of
the classroom, you can't do it.
Kevin Venzke
I think it boils down to personal preference. ESM's
interface, where you get a "standard" menu but then
a separate menu if you select an item, isn't all that
far removed from the interfaces to the LucasArts
Scumm games (Monkey Island, et al). Whether you
like this type of interface better than a command line
or not is personal preference, but many of the Scumm
games are brilliant and prove you can implement
great puzzles with a point-and-click interface. Yes,
ESM is a step further away from a command line,
and the other games on Adventure Games Live are
a step further still; nevertheless, some pretty
satisfying puzzles are still possible.
As an example, in one of the AGL games, you're trying
to surreptitiously steal a painting off a wall -- but the
problem is that servants are hopping in and out of
the room as they set the table. You can try to time
your movements so you're swiping the painting when
they're not in the room, but you soon discover that
you're never left alone for long enough. The solution
(spoilers for "Game of the Ages" coming) is to get
up on the roof, tie a rope in a spot that hangs over
the room, climb down and into the window to the
kitchen, which adjoins the dining room. Knock over
a pot of food -- the disturbance attracts the servants
inside, and while they're busy cleaning it up, you make
a beeline back up and around, never deviating from
the shortest path or consuming time on other
activities, lest you take so long, the servants get the
mess cleaned up and resume their normal duties.
The point I'm trying to make is that the menu interface
is beautifully suited to preserving the "gameplay
experience" of this particular puzzle. Everywhere you
can go and everything you can do might be spelled out
for you, "stripping the player's need to discover what
the useful options are," and yet the puzzle is still very
much a challenging and satisfying puzzle, because the
player must figure out how to coordinate a lot of
different characters, objects, and locations in a certain
logically-deducible way to solve the puzzle. You can't
just push buttons until you stumble on the solution --
you have to devise the solution logically, then carry it
out.
Of course there are certain types of puzzles that
a command line interface is better suited for, but there
are others where a menu works out better, too. As a
teenager, I actually experimented with hybrid games,
which presented you with a command line in some
places and menus in others. Since those days, I've
decided that my personal preference is for menus and
the particular types of puzzles menus are suited for.
If you prefer a command line, that's great. But I don't
think there's a compelling argument for the inherent,
objective superiority of one over the other.
By the way, I agree that the opening puzzle of ESM is
a weak one. If memory serves, it's actually the *only*
"repeat action" puzzle in the whole game. I fully
acknowledge that this makes getting into ESM as a new
player a bit rough. On the other side of the coin, though,
it seems that every other group of new people I've
introduced to it has been more patient about taking the
time to get into the game. Of all people, I would have
thought hardcore IF gamers would have the longer
attention spans.
> Even if you can't get ESM into an unwinnable situation, you can
> still close off possibilities that you might have been able to see if
> you had progressed more slowly. Offering the teacher a cookie
> is an example: You don't have to do it, and once you're out of
> the classroom, you can't do it.
Yes, but in general the games are designed so it's
fairly obvious *when* you're about to close off
possibilities like that, as in this case. But I sympathize
with what you're saying, especially if you've grown
accustomized to having an 'undo' feature available.
My greater frustration is with games designed such that
'undo' is ever needed -- so, with well-designed games, I
personally never miss it. *shrug*
--
Regarding the issue of delays with page loads, I'm still
kind of surprised at the percentage of people here who
are finding the delay unacceptable. Nevertheless, the
suggestion to try out an AJAX interface is a good one,
and I hope to experiment a bit with doing that in the near
future.
<massive snip>
> By the way, I agree that the opening puzzle of ESM is
> a weak one. If memory serves, it's actually the *only*
> "repeat action" puzzle in the whole game. I fully
> acknowledge that this makes getting into ESM as a new
> player a bit rough. On the other side of the coin, though,
> it seems that every other group of new people I've
> introduced to it has been more patient about taking the
> time to get into the game. Of all people, I would have
> thought hardcore IF gamers would have the longer
> attention spans.
It's probably not a matter of attention span. People who haven't
previously been exposed to IF tend to be much more forgiving of things
the IF community think of as substandard. (This isn't to say the IF
community is right about that in the general sense, only from the
criticial perspective of IF.)
>> Even if you can't get ESM into an unwinnable situation, you can
>> still close off possibilities that you might have been able to see if
>> you had progressed more slowly. Offering the teacher a cookie
>> is an example: You don't have to do it, and once you're out of
>> the classroom, you can't do it.
>
> Yes, but in general the games are designed so it's
> fairly obvious *when* you're about to close off
> possibilities like that, as in this case. But I sympathize
> with what you're saying, especially if you've grown
> accustomized to having an 'undo' feature available.
> My greater frustration is with games designed such that
> 'undo' is ever needed -- so, with well-designed games, I
> personally never miss it. *shrug*
The undo feature is not just a player convenience, although it started
that way. The way many IF games are designed is influenced by the
availability of undo and this gives authors a wider palette to work
from.
Apart from anything else, my main use of undo is not to literally undo a
mistaken action, but to explore the range of allowed actions. "Will this
work? Yes. Do I want to do it? Maybe. > UNDO".
--
James Mitchelhill
ja...@disorderfeed.net
http://disorderfeed.net
The syringe puzzle requires repeats.
Also, IIRC, those puzzles don't give any particular reason to try the
action again; the player might as well retry any action that failed.
> Yes, but in general the games are designed so it's
> fairly obvious *when* you're about to close off
> possibilities like that, as in this case. But I sympathize
> with what you're saying, especially if you've grown
> accustomized to having an 'undo' feature available.
> My greater frustration is with games designed such that
> 'undo' is ever needed -- so, with well-designed games, I
> personally never miss it. *shrug*
I've missed it, not so much to get rid of something I've done, but to
avoid going back through menu lists.
And you can close off significant things; if you do things out of order,
you can get locked out of getting the eraser, for one thing.
> Regarding the issue of delays with page loads, I'm still
> kind of surprised at the percentage of people here who
> are finding the delay unacceptable. Nevertheless, the
> suggestion to try out an AJAX interface is a good one,
> and I hope to experiment a bit with doing that in the near
> future.
I've found the delay time varies. Occasionally I've gotten quick action;
early this morning I had 5 second delays.
Also, if a game lasts 4000 moves, even a 1 second delay adds up to an
hour.
You're right. I forgot about that one. That one actually
makes fun of repeat-action puzzles, in a way -- there's a
minor easter egg if you continue searching several times
*after* finding the syringe.
> And you can close off significant things; if you do things out of order,
> you can get locked out of getting the eraser, for one thing.
Yes, but that's sort of a special situation. It's only required
to find the secret area, which is intentionally something
difficult to find. As such, it's exempt from the more usual
design guidelines that non-essential but interesting things
not particularly get cut off unless the player realizes it.
In any case, the eraser is virtually always found with natural
play: try out the new options in a new area, and you've got it.
But I do see your point.
> I've found the delay time varies. Occasionally I've gotten quick action;
> early this morning I had 5 second delays.
I had a script on my server freak out around that time. It's
something I changed a couple weeks ago, and now I'm
wondering if it's been causing sporadic performance problems
more than just this morning. I'll take a look at it, anyway.
Thanks.
> I wanted UNDO when I left the classroom without the backpack
> and the game criticized me for it. Playing again, it turns out that you
> can't (as far as I can tell) actually take the backpack with you, but
> the game criticizes you then anyway.
I happen to like Adventure Games Live, but I'm not a seasoned player of
traditional IF; prior to discovering AGL, my only real experience with
traditional IF was probably Infocom's Hitchhiker's Guide to the Galaxy.
So the notion of an UNDO command was totally foreign to me. (If the
Infocom game did have that option, I couldn't get it to work.) I was
just grateful for the ability to undo fatal moves.
However, when I first played Escape From St. Mary's, I was well
acquainted with the AGL games at that point. So I knew the repetitive
tendencies, and knew that if repeating an option caused slightly
different responses each time (first just the teacher yells, then Zebo
stirs, then Cornell kicks his bag), it usually meant something.
When I got out of the room sans backpack and got the note, "Plus, uh,
you left your bag behind. Maybe you should have taken it with you.
Oops." I wasn't worried. I didn't take that as the game scolding me.
Relatively speaking, it wasn't much of a criticism. (Having played the
more blatantly silly Fantasy Quest games, which give you the option to
do really stupid things and then mock you for it, that was nothing.)
Besides, if you do miss something necessary to win an AGL game, the
game usually gives you the opportunity to go back and get it. Or undo
if it gets you killed. Since I didn't have the option to go back and
get it, and since every time I tried to pick up my bag I put it down
again, I figured that leaving the backpack behind was supposed to
happen.
> Even if you can't get ESM into an unwinnable situation, you can
> still close off possibilities that you might have been able to see if
> you had progressed more slowly. Offering the teacher a cookie
> is an example: You don't have to do it, and once you're out of
> the classroom, you can't do it.
Again, this is colored by my prior experience with AGL games, but I
consider most of those possibilities to be Easter eggs, something you
can try out on a second run through just to see what will happen or to
see what kind of in-joke was tossed in there. The eraser issue is an
exception; while I had no problem with not being able to get to the
secret area after you do something seemingly suicidal in the game -
since this is a major action that takes you to the point where you can
reach the finale - the eraser was a rather obscure and random item that
could only be obtained before you'd solved one of the major tasks by
doing something futile. Most players try to find the secret area after
completing most of the major tasks. I only got to the secret area
because I'd been lucky enough to get the eraser again the second time
through.
My point is, that if a player is unfamiliar with Adventure Games Live,
Escape from St. Mary's is NOT a good game to begin one's experience
with. The inventory interface, for one thing, is unique to ESM; all the
other games usually give you an option to use something right when
you're at the correct screen to use it (and if it doesn't work, the
response usually hints as to why). The initial puzzle didn't drive me
crazy because I was familiar with the repetitive solutions in many of
the games and knew what clues to look for to tell me if the repeated
action was the right one. Nor did the initial loss of the backpack
since I knew that if I really HAD screwed up, I'd have the option to go
back and get it.
The "seemingly useless" options are usually there for humor, and I also
think they serve to add to the challenge a bit. I remember going nuts
in HGttG trying to guess at verbs and items the game would accept - in
contrast, having all the possible options listed in front of you is
light-years easier. If you can't stay dead and you have the selection
narrowed down that much, the challenge severely drops. The additional
silly options balance that out slightly in that not all the options
will really work, and will occasionally give you an amusing response -
and sometimes a seemingly ludicrous option is the right one. After
dying about thirty times in the Vogon airlock trying to get the atomic
vector plotter before getting spaced, I found this trade-off fairly
appealing.
I'd say more, but I have to get going. I do think that in the end, it
probably boils down to personal preference. I happen to enjoy the AGL
games. I think the original review was harsh because it was for a game
that is not a good game to begin with if you're new to AGL.
-Mandi O.
> I'm not complaining about the response time in itself. It's the
> response time together with...
I've solved the mystery of why these response times are so high
and out of whack. It was a bug/flaw that caused *recent* registrants
of Adventure Games Live to have long delays, while the earlier
registrants continued to experience quick response times. Hence
why myself and some other veteran AGL players had no problems,
while you two and others in this newsgroup did.
I've fixed this problem.
Since the fix that I put in earlier this afternoon, I reduced the
delay experienced by a new test account from 3-4 seconds
to a quarter second, tops.
If any of you would have been interested in Adventure Games
Live but for the long lag times, I highly recommend giving the site
a second shot and seeing for yourself if the response times are
more acceptable now.
Cheers.
-- Sam.