Walkthrough comp: reviews/critiques (long)

7 views
Skip to first unread message

Sean T Barrett

unread,
May 24, 2001, 8:33:58 PM5/24/01
to
I wanted to jot down some short comments about these games and
transcripts, but found that for certain reasons I had a lot to
say, perhaps because constrained creativity is a topic that is
near and dear to my heart, and also because being I'm not very
good at being both brief and clear, so I try to favor clarity.
And since I wrote about all of them this came out pretty long.

=
= Jigsaw 2 (Adam Cadre)
= Lighan ses Lion (Andrew Plotkin)
=

The thread running through all the games in this competition
is "game which both would never have been written if not for
this competition and yet does its best to convince you otherwise".
This is less common in other competitions; many mini-comps have
simply restricted games to "genres" we have seen outside that comp
(one-room games, inventory-less games, CYOAs), and games written
for SpeedIFs rarely have the time to try to convince you otherwise.

These two authors (and I think it's no coincidence that it's
two of the most accomplished IF authors) made the most conscious
decision to leave out the "do its best to convince you otherwise".
Instead, the authors saw the opportunity of a new medium, the
opportunity to write games that unabashedly would never exist
outside of the competition.

Adam's game uses the competition walkthrough to humorous ends;
I can even imagine this as him taking his "instead of saying
'it would be cool if', just go write the game" advice (see 9:05)
to an extreme: noticing something amusing about the competition
walkthrough, he chose to make the joke into a game rather than say
it on ifMUD. I don't think it's worth saying more about it; suffice
it to say I enjoyed it thoroughly for its entire length.

Zarf's "game" goes to a different extreme; rather than focus on
the walkthrough, he takes the opportunity to write a transcript
for a game that could never really be. Of course, it does use the
walkthrough, but I suspect the value is in its entire construction,
not in how it cleverly builds on particular properties of the
walkthrough. More I cannot say, since delving into it in detail
did not attract me personally.

Of course, both of these authors might disagree with my analysis,
and whether they do or not, my analysis might be right or wrong;
sixteen possibilities all told, so I suppose the odds that I am
both right and that they would agree with me are low. I'll spare
you "A Dark and Flamey Posting", my choose-your-own-followup game
exploring that space, with its easter egg location "Replying
About Jigsaw 2 (as Adam Cadre)".

=
= Constraints (Stephen Granade)
= Deus Ex Machina (Gunther Schmidl)
=

I have chosen a rallying cry for my criticism of this comp.
That cry is:

WHY A DUCK?

A better cry would be "WHY A LION", since almost all of the
games have one of those, whereas half the games choose to have
something flying at your head from out of the corner of your
eye instead of an actual duck, but I prefer the sound of
"WHY A DUCK".

The point of the cry is that few of the games met the challenge
full-on, answering the question "why is there a duck in the
game" plausibly. Constraints answers it a little, but it
quickly invites more questions.

To address the broader question implied by "Why a duck?":

Constraints answers the challenge of the comp by piling on
nearly every strategy known to mankind. Where Dreams uses
a surreal setting, Constraints uses four different settings,
three of which allow "strange" actions: a world of magical realism,
surreal dreamworld, the "real" world, and a fantasy world. The
use of multiple disparate sections is itself a strategy for
combining the multitude of actions found in the transcript.

DEM does something similar, although without all the
variations, and steering more in the direction of the absurd
than the surreal; the author seems well aware of the
implausibility of the whole thing, given his willingness to
title it as he did. In DEM and Constraints, the real world setting
is used to bring all the chunks together, and they are perfectly
realistic and plausible in this way; and yet I can't help
feeling that if one's goal is to create a game with a
plausible independent-of-the-comp existence, surrealistic actions
combined with "it was all a dream" is a cheap way out.

Then again, it worked for The Wizard of Oz.

[Perhaps I am being unfair to Constraints because I liked
the first room of the game so much I was disappointed that
the game didn't actually deliver that "promised" experience,
and am unfairly holding that against it.]

Constraints gets points for connecting the story in its
"real world" with the theme of the comp, as reflected in
the title; DEM's title also connects to its story beyond
simply reflecting the mode of its plot.

One more nice thing about Constraints...

[Gameplay spoilers for Constraints in the next paragraph.]

There is a level on which the author is not concerned about
plausibility that is I think one of the crowning moments of
this game (much like in Jigsaw 2). The author manages to
introduce at least one puzzle *for* players who *are* playing
from the walkthrough, and if you haven't played it and are
planning on playing it, just stop now, okay? Anyway, when
a confronted with the sequence "TAKE NEXT TURN SMOOTH DUCK...",
a player might type "TAKE", which picks up some random object.
The player quickly discovers that "NEXT" is not a verb, so UNDOes
and tries "TAKE NEXT". Instead of taking an object, this appears
to mean "WAIT", which is a bit odd, until the player realizes that
"TAKE NEXT TURN" is a "plausible" synonym for "WAIT" (not that it
would ever appear in a real walkthrough, so plausibility founders
a little bit, but that's seemingly unavoidable in this comp).
There is, at this point, a duck, one who can be seen to smooth
his feathers, so it is with some confusion that the player finds
that "SMOOTH DUCK" is not accepted, because "SMOOTH" is not
a known verb--which means adding even more words on the
end isn't going to help, and suddenly the player (well, I did)
has a confused moment: a puzzle even though there's a walkthrough.
I was *very* impressed with how Stephen pulled this bit off,
and I don't think anybody else in the competition came close
(probably because they didn't try), although he achieves a
similar effect with "SWITCH PLOVER...".

[Also, in the process of playing Constraints, I discovered
that Tads is rather arbitrary about what effect UNDO has
after a parser failure; UNDO would step back before "I don't
recognize that sentence" properly, but after "don't know the
word" it would seemingly undo the previous command as well,
as if it didn't count.]

=
= Dreams Run Solid (Caleb Wilson)

Where Constraints is all over the map, Dreams runs straight
with a very consistent surreal tone. I think of all of the
entries that were actual games, this one seemed to me to
be the most plausible "could exist outside the comp", although
that degree of plausibility is still not very high. But I
think it works better as a game than Constraints, despite
the fact that I had 10x the number of things to talk about
with Constraints.

=
= Twilight in the Garden of Exile (Alexander Spiridonov)

This game seemingly hung WinFrotz rather early on. (I say
seemingly because maybe there was some magic keystroke I
was supposed to press--for example, for a while I thought
Walk Through Forever had crashed, until I thought to look
at the status line. I know Pytho's Mask is great and all,
but I really wish people who want to do this sort of thing
would switch to a development system that allows the
"status line" at the bottom (for Inform authors, that would
be Glulx). Input does not belong at the top of the
screen. Heck, neither do status lines, according
to the human factors literature; it was just a convenient
hack for traditional scrolling outputs, which would scroll
it off the screen and then you just redrew it. We can do so
much better today; note where the status line in most GUI
programs is.) So I can't really say much about it, hence the
huge parenthetical comment about a different game.

Well, and one more thing. Twilight offers the archtypical
example of what I'm calling a "non-puzzle." There's an
object. To open it, you need the password. True to walkthrough
form, you can just type in the password without learning it
in-game. But, just for the sake of thoroughness, what is the
puzzle? If you go off-walkthrough, how do you discover it
in-game?

By examining the object.

Throughout most of the comp games there were an awful lot of
non-puzzles like this.

=
= A Walk Through Forever (Duncan Cross)
= A Venture (Denis Hirschfeldt)
=

Why a duck?

Both of these games try to cover up their absurdity by asserting
that they are "bad" games--WTF supposedly incorporating a goofy
game the protagonist threw together quickly, and Venture supposedly
being an "old sk00l" game.

They are both kind of fun in their own way. WTF's bad
game seems kind of pointlessly bad, though, bad to the point of
not too fun, although the author makes up for it with things like
"A voice from the audience calls out, 'OPENING SQUARE BRACKET'";
but the author seemingly ran out of steam and decide to put in
an interminably long unfun sequence which, at least, demonstrates
that Graham Nelson was wrong: a crossword can BE the narrative.
(Although the section is vaguely amusing in a sort of meta-
way, but Jigsaw 2 does it better.)

A Venture has some really beautiful touches--like its use
of "ON"--but it also doesn't go to any effort to hide some
absurdity that is beyond absurd, like the "WAKE FISH" sequence.
Well, it does, through its meta-commentary, which is basically
to point out just how hard and unforgiving these "really old
skool" games are--they're not your father's old skool games.

The walkthrough sequence "DRAW SWORD WAVE FAN DANCE ABOUT PAINT"
was apparently a very hard one for most of the games in the
competition to address plausibly; both of these games use it
as essentially a time-killer, although Venture makes it a bit
more interesting than that--but the point is that the way in
which the commands advance the game has very little to do
with what the commands actually accomplish.

=
= Bollywood Hijinx (Jamie Murray)
= A Very Strange Day in the Life of a Maid (Mel Brittingham)
=

One of the joys of fiction is that you get the opportunity to
experience a new world, something you've never seen before.
So I was interested in Bollywood's setting--especially
after reading Emily Short's comment on it--and was a bit
disappointed with what I actually got; I'm not clear that
anything in the game would change if it were rewritten as
a wacky game set in Hollywood instead.

A problem I have with these two transcripts is I can't believe
in them as transcripts. To some extent that they hew to
the form of adventures, by being present-tense second-person with
prompted imperatives that specify the actions of the protagonist;
but Bollywood lacks room descriptions and any sense of "place"
as it unfolds, and both have an awful lot of people just
walking by at random at appropriate moments in the transcript,
without trying to establish their existence previously; they
don't have a real feel of being fuses and daemons. Ok, actually,
Strange Day doesn't seem to have that many (the muffin is a
notable example), but I definitely came away from it feeling
that way.

Bollywood at least made up for it with some cute moments, like
the context in which "LION" and "PRAY" are brought together.

=
= Time Bastard (Matt Francisfordcapollasdracula)
= Persistance de la Vision (J. Robinson Wheeler)
=

Of all the games in the comp, I found these two to be the
most plausible, the most convincing. I say that about Persistance
with severe hesitation. I played Time Bastard last, so my
expectations were very low by the time I got to it, and I was
pleasantly surprised to see how successful it was. [As I go
through this fixing grammar and spelling, I note that I wrote
"played" instead of "read", and I think that reflects just
how convinced I was.]

All through my reading of Persistance, I apparently misunderstood
the tone of voice the author intended. There's clearly some
conscious irony: TAKE ALL, or the exchange
"You have free will, Henri," says Jean-Claude.
"Not hardly," you sigh.
(which might have one ironic meaning in IF, where the player is in
control, not the PC, but which takes on a different meaning in a
game so obviously on rails). Because of that, and the implausible
inference from the parser at the beginning ["THINK (about Stephanie)"]
I had a grand old time reading the whole thing imagining the
author chuckling over my shoulder at the sheer implausibility
of the whole thing *as a game*; the fact that nearly every
command is effectively triggering a cutscene, the fact that
most commands are spelled out to the player in the last
paragraph before the prompt. But on reading the author's notes
it seems he was serious about the material, at least as a
story, so I suspect that I was reading this tone of voice into it.

And so I have a lot of trouble imagining that anybody would actually
put this thing into a game: except that its author is Rob
Wheeler, and I recently read his essay about his "movie player"
technology used in Centipede; this transcript seems sort of like
the culmination of that strategy, and hey, at least it (perhaps)
makes the player type in the commands instead of typing "Z".
So, if any other author had written it, I would write it off
as "Implausible. A story written in second person present tense,
passed off as a transcript." Instead, in the face of its author's
other work, I have to consider it plausible; at which point its
ranking leaps enormously, because it manages to be the sole game
of the comp to avoid surrealism, absurdity, or wacky silliness.
[Except when it gets to the dream sequence. But so close! I'll
choose to believe that the author did the dream sequence for the
fun of it, not because he was too constrained.]

Time Bastard, on the other hand, combines the rather strange
elements of time travel, Lovecraftian mythology, and a small
amount of wackiness into a whole that is vaguely plausible.
It's perhaps not hugely plausible, but it has a relatively
coherent world-logic without appealing to "surreal logic"
the way something like Dreams does. Moreover, it pulls out a
twist ending which gives it a grounding in the real world
just as much as Constraints does; so these two aspects together--a
comprehensible logic for the weird parts, and an ending that
puts it all together in a much-less strange way--combine to
create a game that I *could* imagine being written independent
of the competition.

For example, I think the game section in Time Bastard for
"STAND ON EAST SWING KNIFE LION PRAY" is the most convincing
of the comp: a multi-stage puzzle set in a single scene,
with all of the components evolving naturally; and while
there is a certain silliness to the narration, the
situation itself is quite believable. (Time Bastard also used
a single technique to work around the odd "ZRBLM" and "XYZZY"
commands, which was an example of a *good* way to use the
same strategy to get around two problematic commands.)

Time Bastard is (I think) the only transcript which chose
to include off-walkthrough commands, which is crucial to
creating this believability. It's *possible* that Persistance
wouldn't need so much leading text if Rob had done this,
but I have my doubts, since its narrative seems to need
to run continuously the way it does, without slowing down
for off-walkthrough turns.

=
= Fit for a Queen (Margia McPolti)

Actually this game was written by me. I hadn't planned on
admitting to it--my oeuvre of released games now comes to
three games written under time pressure, none of which are
at all representative of my WIPs or what I *want* to be
doing on a large scale, and which play less to my strengths
as a programmer and more to my weaknesses as a writer--but
I feel it would be dishonest to make the previous comments
without admitting to it.

So I will take this as an opportunity to talk a bit about
rails. First let me say that I find it ironic in the Alanis
sense that the author of Galatea and Metamorphoses (and
perhaps A Dark and Stormy Entry?) should run a competition
in which every submitted game is on rails, often on huge,
enormous, blatant rails.

[Every game, AFAICT, except Margia's, the first two-thirds of which
(six rooms) can be done in mostly any order, and the last third of
which was on rails as a sort of parody; had I known what the other
games in the comp would look like, I wouldn't have bothered
parodying rails. Then again, I guess what I discovered, struggling
with the added constraint "not on rails", is that this was too many
constraints; I stayed off rails at the expense of "continuity", hence
my choice of genre to try to mask this.]

Admittedly, given the relative successes of "Being Andrew Plotkin",
"Shade", and "Rameses", being on rails may not be such a bad thing.

I guess the issue here is that they're not just on rails, or maybe
it depends on how you define "being on rails". There seem to be two
major additional issues in my mind: the degree to which the player
character takes actions without the player choosing them, and the
degree to which actions taken have unpredicted consequences.

The phrase "on rails" means many things, but the overriding idea
that it is normally used for seems to be a heavy linearity: at each
point in the game, you can only do the thing that the author allows
you to do; you can perhaps bash around in place trying other things,
but nothing is going to happen until you do that one action.

The thing is, games "on rails" often still try to give the player
the illusion of control--the actions taken by the player character
are the actions specified by the player; you are simply constrained
to taking the linear sequence of actions that the author has come
up with for you to follow along.

So let me define some terms. I'm going to use "on rails" to mean
what I just said above: strictly sequential sequences of allowed
commands. I also want a term that refers to the fact that the player
character takes actions without the player requesting them; this
is common in cutscenes, but I don't want to confuse this with
proper cutscenes (which need not even involve the player),
so I'll call this "uncontrolled". Finally, there's the fact that
commands entered by the player can have unexpected consequence;
I'll call this "unpredictabile". (Of course, a certain level of
unpredictability is always required in every game, or it's not
really a game.)

Let's look at the three games mentioned before. I just picked those
three off the top of my head as representative games from the last
comp, so they may not be an ideal set, but what the heck. I'm also
going to characterize them from memory, despite the fact it's been
more than half a year, so I may get this wrong.

"Being Andrew Plotkin" has some major cutscenes, but I don't
recall it as being that uncontrolled. The player still chose to
sort the files, open the file cabinet, open the door, enter
the tunnnel, etc. Similarly, sorting the files sorted the files;
opening the file cabinet didn't, since it was stuck; opening
the door did; entering the tunnel did, although it led to strange
consequences; so I'd deem BAP neither "uncontrolled" nor
"unpredictable" in the senses I've defined.

"Shade" was not at-all uncontrolled. Nor was it unpredictable,
exactly; the actions had unpredicted consequences at first,
but they quickly became predictable--and this unpredictable
consequence was really the whole point of the game in the
first place. So I'd deem it neither.

The famously ineffective parser in "Rameses" I would tend to
deem "unpredictable"; clearly in some cases the player character's
actions are not the choices of the player, but that's not really
my point of "unpredictability"--Rameses is a special case here,
since it's not merely the consequences of the action that are
unpredictable, but the action itself. I can't remember how
uncontrolled it is; somewhat, certainly, but I think the game
tended to give you a parser prompt when it was time for something
major. You could argue that that whole parser refusal business
is more a matter of "uncontrollability" instead of "unpredictability",
I guess.

Why are these issues? Well, uncontrolledness just robs the game
of being interactive at all. Unpredictability tends to lead to
non-puzzles and anti-puzzles and unmotivated gameplay. Here's
a fictitious example Adam Cadre invented in his comp00 reviews:

You're in a cell. You want to get out. The door won't budge,
and there's a guard posted outside. You have a gold coin.

GOOD DESIGN:
Get the guard to open the door and let you go free in exchange
for the coin.

BAD DESIGN:
Swallow the coin. This randomly causes the door to fall off
its hinges onto the guard, allowing you to make a break for it.

Unpredictability can lead to bad design. Fortunately, most of the
walkthrough comp games avoided this flavor of unpredictability;
instead, the action had its intended consequence, solving the puzzle,
but would lead to a further unexpected consequence; let me expand
Adam's example with

SURREAL DESIGN:
Get the guard to open the door and let you go free in
exchange for the coin, but when he opens the door,
the door turns into a duck which eats the guard...
and now you have to get past the duck.

Is this good or bad design? The unpredictability doesn't make puzzles
unsolveable, but it tends to mess with the sense of overall motivation
and progress toward a goal; you're constantly overcoming obstacles
that you'd never seen until the previous turn. This is clearly
connected to being "on rails", yet not strictly the same thing.

[And none of this even addresses the "leading" I discussed previously,
where the puzzles are non-puzzles because their answers are explicitly
spelled out in the output from the previous command.]

So how, IMO, do the games stack up in forcing the player forward,
in terms of the three jargon terms I'm using here, "on rails",
"uncontrolled", and "unpredictable"?

Time Bastard: on rails, unpredictable at times
Persistance de la Vision: on rails, uncontrolled
Dreams Run Solid: on rails, unpredictable
Constraints: on rails, unpredictable
Walk Through Forever: on rails, unpredictable
Bollywood Hijinx: on rails, unpredictable
Deus Ex Machina: on rails, unpredictable
Very Strange Day: on rails, unpredictable
A Venture: on rails, unpredictable
Jigsaw 2: on rails

So, ok, there wasn't that much use to that exercise, except that
if you go along with my analysis you can see that these games are
a lot more unpredictable than the comp "on-rails" games. I think
"Time Bastard" and "Being Andrew Plotkin" are actually probably
similar, but I'd need to replay BAP to be sure.

For comparison, in the main section of Fit for a Queen, there are
only a few unpredictable moments, if you stop to examine things
first--for example, the consequences of "SEAT ZRBLM" and "WAVE FAN"
are clued--but there are exceptions; TURN SMOOTH DUCK and the final
outcome of BOWL (although the latter was for tone, not constraint).
The only uncontrolled actions are stepping through the door when
you unlock it and falling off a platform, which are very minor.
To me, all of this makes the game a more plausible actual *game*:
you have a goal, you can try to achieve the goal, and you can
see how most of the actions you're taking are getting you closer
to your goal (if you don't stay strictly on the walkthrough). And
achieving all that was the goal I set myself for writing this game.

===

A few comments about common threads to the games:

Almost all of the games avoided the "obvious" interpretation
of DRAW SWORD and as a result picked roughly the same
interpretation as each other... leading me to question
what it means to be "obvious". The game Constraints rather
cleverly combined both meanings.

Sleeping fish form another theme; some games avoided it
by reading the walkthrough differently, but Time Bastard
addressed it head-on in a very clever way--one that I
kicked myself for not seeing coming.

Despite the lack of motivation for it in the walkthrough,
two games make reference to tentacle porn, and that's not
counting Time Bastard.

A few games made use of parser followup questions, despite
the way this is unnatural in a walkthrough; SWING KNIFE (at) LION,
SWITCH PLOVER (with) EGG, LOOK UP DRESS (in) BOOK [it was
interesting to see the more clever ways of avoiding the
"obvious" interpretation of "LOOK UP DRESS"]; admittedly,
my game seems to have done this more than any other.

Nearly every game ended up with some unused commands, although
I think nearly every author was working under the aesthetic
that including unused commands was inappropriate (Dreams Run
Solid has so many that I don't think it was intended to, and
there *is* a school of walkthrough that includes extras). From
my notes, it appears that (ignoring the alpha and omega of
the comp, Adam and Zarf's games) none of the actual games used
every command; of the walkthroughs, Time Bastard is the obvious
exception, although I don't didn't take notes about several
of them, so A Venture may also have succeeded on this front.
(If someone wants to debate this, I'll post the specifics.)
There is an overall pattern here which is, I guess, not very
surprising: the transcripts manage to meet both the "use
every command" and "plausible comp-independent existence" more
effectively than the actual games; not very surprising because
I imagine that the transcripts would require a lot more effort
to actually turn into games than any of the actual games took
(although, actually, I'm not sure Time Bastard would be that
much bigger than Fit for a Queen).

SeanB

Sean T Barrett

unread,
May 24, 2001, 8:38:49 PM5/24/01
to
Sean T Barrett <buz...@world.std.com> wrote:
>near and dear to my heart, and also because being I'm not very
>good at being both brief and clear, so I try to favor clarity.

Note to self: in the future proofread AFTER writing the preface.

Emily Short

unread,
May 24, 2001, 10:07:46 PM5/24/01
to
In article <GDv8...@world.std.com>, buz...@world.std.com (Sean T

Barrett) wrote:

> =
> = Jigsaw 2 (Adam Cadre)
> = Lighan ses Lion (Andrew Plotkin)
> =

> These two authors (and I think it's no coincidence that it's


> two of the most accomplished IF authors) made the most conscious
> decision to leave out the "do its best to convince you otherwise".
> Instead, the authors saw the opportunity of a new medium, the
> opportunity to write games that unabashedly would never exist
> outside of the competition.

<snip a fairly large amount of prose>

I think the message I would extract from the comp at large (and yes, I
realize this is a bit skew since I was free to judge on this principle) is
that the most successful games/transcripts/works are those with a clear
strong sense of their own identities. Adam's and zarf's entries
unquestionably had this; so did 'Time Bastard' and 'Persistance,' more
because of attitude than because of Clever Trick.

Here is where I find it interesting about the side material that appeared
in this comp. The artwork accompanied three of my more-favored entries;
the "box cover" for Time Bastard seemed particularly efficacious to me,
because it managed to sum up most of the flavor of the game. Likewise I
really liked the 'background' material that came with 'A Venture' and 'Fit
for a Queen.' I'm not sure whether anyone else will agree with me, but I
consider this vindication for my earlier assertion that games are more fun
when they come with feelies.

> at the status line. I know Pytho's Mask is great and all,
> but I really wish people who want to do this sort of thing
> would switch to a development system that allows the
> "status line" at the bottom (for Inform authors, that would
> be Glulx).

I am. Just as soon as I get the kinks worked out. I did, actually,
attempt to switch to glulx for the revision of Pytho (version 2 is out,
btw, but still hanging around incoming; it does relatively little
spectacularly new, but I think I've worked out some of the more egregious
bugs from v1). Unfortunately, I had various and sundry Problems getting
the Mac compiler not to crash spectacularly, taking my whole system down
with it. For another project, perhaps.

> So I will take this as an opportunity to talk a bit about
> rails. First let me say that I find it ironic in the Alanis
> sense that the author of Galatea and Metamorphoses (and
> perhaps A Dark and Stormy Entry?)

Yes. Though let me say that -- exactly because of the comp games you
mentioned elsewhere -- I've gained a certain amount of respect for the
rail-game as well, and my almost-complete WIP is fairly railroady in parts
because of the plot I was comissioned to follow. It's an interesting, but
other, challenge than the one I usually take up. More power to the
writing, I guess. I used to have doubts about a work of interactive
fiction where the player was like the organ grinder's monkey, just there
to turn the crank and make it go, but I've decided that even that conveys
a sense of involvement and responsibility that doesn't always occur in
'normal' literature.

> should run a competition
> in which every submitted game is on rails, often on huge,
> enormous, blatant rails.

Well, okay-- though admittedly it wasn't as though this came as a surprise
to me. I realized what a weird walkthrough that was, and what was likely
to result. Sort of. I'm not sure I realized how many entries there would
be or what the cumulative effect of reading it would be. WEIRD, guys.
GET OUT OF MY HED.

I will dream of sleeping fishes...

ES

(Oh, and a side note. Matt Fendahleen asked me if I had a game in mind
when I wrote this. No, I didn't; but I did have scenarios in mind for
many of the subparts of the game. The whole DROP TOY SLEEP thing was
meant to be about a yoyo trick. And I am SO DISAPPOINTED that no one--

Well, no, I'm not, really. But I did have things in mind; some of which
were picked up on, and some of which weren't. Mostly it was wordplay
ideas. I *am* still faintly sad that no one took up the purely linguistic
side of this and made a game breaking the walkthrough the longest possible
commands, e.g.)

--
Emily Short
http://emshort.home.mindspring.com/index.htm

Sean T Barrett

unread,
May 25, 2001, 2:32:16 AM5/25/01
to
Emily Short <ems...@mindspring.com> wrote:
>I *am* still faintly sad that no one took up the purely linguistic
>side of this and made a game breaking the walkthrough the longest possible
>commands, e.g.)

Unfortunately I only thought of that sort of thing in hindsight
when I saw how delightful commands like "READ LOOK UP DRESS BOOK"
were. I'd have to say that the extra constraint I chose to put
on it turned out to be the least interesting one to do (although
for me it was good practice for doing a comp game), and numerous
other ones suggested themselves to me after I was already committed
to the approach I took: the game in which every noun in the walkthrough
referred to the same object; the two-room game in which every compass
direction leads to the other room--heck, the one room game with
vast quantities of stuff in it. But I suspect that adding further
constraints to the ones already in the comp generally reduces the
quality, though you could argue that another constraint shouldn't
prevent one from having a strong independent identity. But it
makes me think of Hofstadter's description in "le Ton beau de Marot"
of how he and his friends were able to communicate fine using only
e-less lipograms, but switching to no 'e' AND no 't' simply ended
the conversation. (The faux mud transcript in 'Fit' is an e-less
lipogram to celebrate the constraint-spirit of the comp.)

I think the choice of walkthrough had a really big impact there,
although I don't think it was a bad choice--the games might be
just as varied but there would be less coolness to them if the
walkthrough had read "N.N.E.GET BALL.W.S.W.PUT BALL IN BOX.".
If I were to try to improve the walkthrough I would strike some
of the two weird words (ZRBLM and XYZZY), three meta-commands
(HELP, ABOUT, and UNDO), and four sensing commands (X, LISTEN,
LOOK, and EYE), which I think required too much effort to work
into the games effectively for too little payoff--but this is
far easier to propose in hindsight, and even then I'm not sure
how many would be best cut.

Certainly I think the whole thing came out pretty well as it
was, or I wouldn't have written so damn much about it.

SeanB

Gunther Schmidl

unread,
May 25, 2001, 3:55:48 AM5/25/01
to
Sean wrote:

> DEM does something similar, although without all the
> variations, and steering more in the direction of the absurd
> than the surreal; the author seems well aware of the
> implausibility of the whole thing, given his willingness to
> title it as he did.

In fact, as Emily noted in her review:

"Would I like to play an implementation of this? I can think of little more
frustrating."

That was my intention with this - to write the walkthrough for a game that
couldn't actually be played without a walkthrough in the real world, because
people would be throwing their computers out of the window in fits of rage.

That said, I'd be interested to see how a game with split narrative[*] would
be accepted by the audience.

[*] For lack of a better term. What I mean here is:

| You can make out something glittering coming at you full speed--
|
| >DUCK
| -- and duck just in time to avoid being cut to pieces.

-- Gunther
-- http://www.fourcoffees.com

Sean T Barrett

unread,
May 25, 2001, 9:55:12 AM5/25/01
to
Gunther Schmidl <gsch...@gmx.at> wrote:
>That said, I'd be interested to see how a game with split narrative[*] would
>be accepted by the audience.
>
>[*] For lack of a better term. What I mean here is:
>
>| You can make out something glittering coming at you full speed--
>|
>| >DUCK
>| -- and duck just in time to avoid being cut to pieces.

Reading it, it has a really nice sense of continuous motion,
which gives a sense of being "real time" despite being turn-based.
However, it relies an awful lot on leading; I think a real play-through
would result in it being too split:

| You can make out something glittering coming at you full speed--
|

| >X GLITTERING
| -- hard for you make out in the gloom, but the dimness seems no
| problem for it to slice your head off.
|
| *** You have died ***
|
| Do you want to RESTORE, QUIT, UNDO, or GRIPE at the author?
| >UNDO
|
| Smooth passage


|
| >DUCK
| -- and duck just in time to avoid being cut to pieces.

Of course, with work you could make that "Smooth passage" reprint


"You can make out something glittering coming at you full speed--"

[this is one of those sections where a transcript cheats by
leaving out room descriptions so it's hard to say what's going on].

But in the general case--if such an event were on a fuse or daemon
in an existing room--you'd be pretty stuck by the fact that 'UNDO'
doesn't replay the previous turn, so timed messages would not get
reprinted. If a terp supports multiple undo, you could actually
change this, by saving undo's after the command runs but before fuses;
but then you're missing narrative in response to the player command,
which suggests making undo jump all the way back to just *after* the
last command; but that would be tedious after cutscenes etc. The best
solution might be to print messages-that-should-be-redisplayed-after-undo
through a special function that saves them away somewhere, and change
the UNDO code to just go print that little queue.

But that all seems like an awful lot of work.

SeanB

Ross Presser

unread,
May 25, 2001, 2:19:51 PM5/25/01
to
ems...@mindspring.com (Emily Short) wrote:

> I used to have doubts about a work of interactive
> fiction where the player was like the organ grinder's monkey, just
> there to turn the crank and make it go, but I've decided that even
> that conveys a sense of involvement and responsibility that doesn't
> always occur in 'normal' literature.

Truly minor nit: Every time I've seen an organ grinder and monkey (in
cartoons, usually), the man is grinding the organ while the monkey
dances around and begs for change.

--
Ross Presser * ross_p...@imtek.com
"A free-range shoggoth is a happy shoggoth, and a happy shoggoth is
generally less inclined to eat all of you at once." - Tim Morgan

mattF

unread,
May 25, 2001, 10:22:32 PM5/25/01
to
> That was my intention with this - to write the walkthrough for a game that
> couldn't actually be played without a walkthrough in the real world, because
> people would be throwing their computers out of the window in fits of rage.


Machina ex Fenestra? =)

-mattF

Matthew W. Miller

unread,
May 26, 2001, 12:26:10 AM5/26/01
to
On Fri, 25 May 2001 00:33:58 GMT, Sean T Barrett <buz...@world.std.com>
wrote:

>= Twilight in the Garden of Exile (Alexander Spiridonov)
>This game seemingly hung WinFrotz rather early on. (I say seemingly
>because maybe there was some magic keystroke I was supposed to press
...

>I really wish people who want to do this sort of thing would switch to a
>development system that allows the "status line" at the bottom

Above or below the prompt? (I'm serious. I use a MUD client called Tiny
Fugue which has a text window, then a status line, then a five-line space
for command entry.)

>Input does not belong at the top of the screen. Heck, neither do status
>lines, according to the human factors literature;

Human factors literature is written by marketing weasels and salesmen.

>We can do so much better today; note where the status line in most GUI
>programs is.

The status line in most GUI programs, I think, is not comparable to the
status line of an IF game. In my personal opinion, the status line of an
IF game is most comparable to the title bar of a window, or the location
bar of a web browser, and where is *that* located? Unless you're using
Opera, it's probably not at the bottom.
--
Matthew W. Miller -- mwmi...@columbus.rr.com

Sean T Barrett

unread,
May 26, 2001, 1:46:31 AM5/26/01
to
Matthew W. Miller <mwmi...@columbus.rr.com> wrote:
>>I really wish people who want to do this sort of thing would switch to a
>>development system that allows the "status line" at the bottom
>
>Above or below the prompt? (I'm serious. I use a MUD client called Tiny
>Fugue which has a text window, then a status line, then a five-line space
>for command entry.)

Hard to say; with a "status line" that changes sizes for different
conversations or whatever, I'm not sure which is better; for a fixed
size status line, prompt above status line. No, wait. I'm not
thinking clearly.

TinyFugue--one word, by Greg Hudson, I think, I don't remember whether
it's a mod of Tarrant's original tinytalk or written from scratch, but
it's the same interface layout--doesn't have the option of things like
reverse video to set things off, so the status line is also used to
delimt the prompt line, since the prompt doesn't scroll up into the
rest of the text like it does in a single-person adventure--all in
all, a very different application, so the UIs aren't that
comparable.

As long as we want the prompt to scroll up into the transcript, the
prompt would go above the status line, the status line at the very
bottom.

>>Input does not belong at the top of the screen. Heck, neither do status
>>lines, according to the human factors literature;
>
>Human factors literature is written by marketing weasels and salesmen.

I mean the kind of human factors stuff where people run experiments
and create things like Fitt's law. It's not hard to base user interface
design on science. Apple used to do it; MS never bothered.

>The status line in most GUI programs, I think, is not comparable to the
>status line of an IF game.

Er... depends on the program. Heck, the status line in games like Doom
are at the bottom of the screen--some designers place that status
info at the top instead, and it noticeably sucks--and there are written
articles from game developers urging other game developers to put it at
the bottom.

*And none urging it be put at the top.*

>In my personal opinion, the status line of an
>IF game is most comparable to the title bar of a window, or the location
>bar of a web browser, and where is *that* located?

I *never* look at the title bar of a window I'm using.
"Telnet - world.std.com". "MS-DOS Prompt". Such useful
information. Of course, an application could put useful,
changing information in a title bar, but then it would
be a status bar. And if you say "status line", people don't
think you're talking about the title bar, at least not
in my neighborhood.

I agree that the status line certainly is comparable to the
title bar of a window insofar as I generally never look at it.
I missed out on the humorous status line in "At Wit's End"
in the last comp because I never looked up at it. And I
missed the prompt in Walk Through Forever for a while. I
constantly miss things in the prompt.

If every command I type produces only two or three lines of
text, then everything I need to read (what I type and the
game prints) is at the bottom of the screen. If the status
line is entirely irrelevant, sure, leave it at the top. But
it would be way more useful at the bottom.

I can't guarantee that I wouldn't still totally miss things
if the status line was at the bottom, but it seems a lot
more likely I'd notice something right next to where I was
already looking.

I may be basing this on personal opinion, but since there's
supposedly scientific evidence *plus* you can explain logically
why it's advantageous with a very simple theory, I don't
really understand your resistance.

SeanB
who used to hang on muds with Greg Hudson while he was developing
tinyfugue, and still hangs on a mud with the Grod who wrote tinywar

Adam Biltcliffe

unread,
May 26, 2001, 6:06:21 AM5/26/01
to
"Sean T Barrett" <buz...@world.std.com> wrote:

> WTF's bad game seems kind of pointlessly bad, though, bad to the point
> of not too fun, although the author makes up for it with things like
> "A voice from the audience calls out, 'OPENING SQUARE BRACKET'";

Don't forget to try pressing caret.


jw


Walter Sandsquish

unread,
May 26, 2001, 12:32:21 PM5/26/01
to
Sean T. Barrett (buz...@world.std.com) wrote:
<<I agree that the status line certainly is comparable to the title
bar of a window insofar as I generally never look at it. [...] If the
status line is entirely irrelevant, sure, leave it at the top.>>

If the status line is irrelevant (and most of the time, I think it is),
why not leave it out alltogether?

I'm not trying to be snide. Some games do put important information
in the status line, but most games just stick your location name and
score up there. I already know where I am in the game. The game told
me that in the regular output window. And score isn't important in
many games.

Magnetic Windows, Telarium, Alan and AdvSys games have no status line.
And I don't miss it when I play those games. Really, I think it makes
the window look less cluttered.

- Walt

Andrew Plotkin

unread,
May 26, 2001, 1:08:35 PM5/26/01
to
Sean T Barrett <buz...@world.std.com> wrote:

> Er... depends on the program. Heck, the status line in games like Doom
> are at the bottom of the screen--some designers place that status
> info at the top instead, and it noticeably sucks--and there are written
> articles from game developers urging other game developers to put it at
> the bottom.

> *And none urging it be put at the top.*

So, I've written Z-machine interpreters for the Mac and for X windows
that put the status window up as an actual separate window. The user
*can* move it below the story window. Entirely the user's choice.

I've never moved the status line below the story window. Does anyone
else do that?

I mean, we can collect data, here.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* My vote counts -- count my vote!

Emily Short

unread,
May 26, 2001, 2:16:55 PM5/26/01
to
In article <9eonuj$omk$1...@news.panix.com>, Andrew Plotkin
<erky...@eblong.com> wrote:

> Sean T Barrett <buz...@world.std.com> wrote:
>
> > Er... depends on the program. Heck, the status line in games like Doom
> > are at the bottom of the screen--some designers place that status
> > info at the top instead, and it noticeably sucks--and there are written
> > articles from game developers urging other game developers to put it at
> > the bottom.
>
> > *And none urging it be put at the top.*
>
> So, I've written Z-machine interpreters for the Mac and for X windows
> that put the status window up as an actual separate window. The user
> *can* move it below the story window. Entirely the user's choice.
>
> I've never moved the status line below the story window. Does anyone
> else do that?

Not I. Though if I'm playing a game with a lot of quotes, I sometimes put
the status bar a couple of inches above the main window so that the
boxquotes have room to breathe.

WRT to the Pytho's Mask menu system, however, I've just finished porting
it (the system, not the game) for glulxability, and the menu can now be
set to the top or the bottom of the screen, at the user's discretion.
I've noticed in play testing that I always opt to have the menu at the
bottom. Not the status line, though. I think the key here is that I want
input-related stuff to be near the place where I'm typing, but status
stuff up where I'm not looking at it all the time. With the menu at the
bottom, I can make the window bigger without feeling like my eye has to
skip up and down all the time.

ES

Sean T Barrett

unread,
May 26, 2001, 3:04:03 PM5/26/01
to
Andrew Plotkin <erky...@eblong.com> wrote:
>Sean T Barrett <buz...@world.std.com> wrote:
>> *And none urging it be put at the top.*
>
>So, I've written Z-machine interpreters for the Mac and for X windows
>that put the status window up as an actual separate window. The user
>*can* move it below the story window. Entirely the user's choice.
>
>I've never moved the status line below the story window. Does anyone
>else do that?
>
>I mean, we can collect data, here.

There's a difference between "I've never tried it" and
"I've tried it and it sucked/made-no-difference." People
are notoriously stick-in-the-muds when it comes to learning
new user interfaces. I'm awful about that: I still use mail ("mailx"?)
and rn (actually trn -x -X or whatever it is) on a unix system.
But changing where you have to look is a lot lower impact
than changing means of interaction.

There might be a plausible "standards" argument: it would be
confusing to play games if some had status lines at the top
and some had them at the bottom.

Some other conflicting factors to watch for in collecting the data:
- do your interpreters remember the window configuration, or must
the user "tediously" reconfigure it each time a (new) game is
started?
- have we reached a point where status lines are so unused (e.g.
games without scores) that the reason nobody moves the status
line is because it doesn't matter because it's just something
to be ignored?

But on another level, I really don't care about the status line
anywhere near as much as the input; the comment about status lines
that started this thread was, IIRC, an aside to an aisde.

SeanB

Matthew Russotto

unread,
May 26, 2001, 3:56:56 PM5/26/01
to
In article <8b3a0406.01052...@posting.google.com>,

Machine ex Defenestra!

--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."

Matthew Russotto

unread,
May 26, 2001, 4:13:23 PM5/26/01
to
In article <9eonuj$omk$1...@news.panix.com>,
Andrew Plotkin <erky...@eblong.com> wrote:
>Sean T Barrett <buz...@world.std.com> wrote:
>
>> Er... depends on the program. Heck, the status line in games like Doom
>> are at the bottom of the screen--some designers place that status
>> info at the top instead, and it noticeably sucks--and there are written
>> articles from game developers urging other game developers to put it at
>> the bottom.
>
>> *And none urging it be put at the top.*
>
>So, I've written Z-machine interpreters for the Mac and for X windows
>that put the status window up as an actual separate window. The user
>*can* move it below the story window. Entirely the user's choice.
>
>I've never moved the status line below the story window. Does anyone
>else do that?
>
>I mean, we can collect data, here.

With the first person shooters, your normal visual flow is up. With text,
your normal visual flow is down. This probably has something to do
with the difference.

OKB -- not okblacke

unread,
May 26, 2001, 7:05:24 PM5/26/01
to
ems...@mindspring.com (Emily Short) wrote:
>WRT to the Pytho's Mask menu system, however, I've just finished porting
>it (the system, not the game) for glulxability, and the menu can now be
>set to the top or the bottom of the screen, at the user's discretion.
>I've noticed in play testing that I always opt to have the menu at the
>bottom. Not the status line, though. I think the key here is that I want
>input-related stuff to be near the place where I'm typing, but status
>stuff up where I'm not looking at it all the time. With the menu at the
>bottom, I can make the window bigger without feeling like my eye has to
>skip up and down all the time.

My feelings are much the same, and this is reflected in GxScript, which
puts the dialogue menu at the bottom of the screen. The input prompt is ALWAYS
at the bottom of the screen (since text scrolls off the top -- what if you were
playing a game in a language read bottom-to-top?). Also, the bottom of the
screen is naturally more "important" since that is where the most recent text
is. In terms of eye movement, it is much less time-consuming to glance from
the input prompt to the dialogue window if said window is at the bottom of the
screen near the prompt. If the window is at the top, the eye must go all the
way up, then all the way back down.

With dialogue menus, especially, the player may look back and forth
between the menu and the most-recently-displayed text in the main window
(reviewing what the NPC has just said in order to decide what to say next).
The more the eye goes from prompt to menu and back, the more noticeable it is
when the prompt is far from the menu.

However, I think dialogue menus are entirely different than the status
line. In almost all games, the status line holds the location name and score,
neither of which is very pertinent to the player's decision-making. The
location is already given in the main text, and the score is not generally
relevant to decisions about what to do next. I personally tend to regard the
status line more as a title than as a current, informative display -- it is a
title for the room I'm in.

In first-person shooters, on the other hand, the information on the
"status line" is much more relevant to the actual play; how many bullets you
have left may well influence your choice of what to do next. At the same time,
room titles are not appropriate (since an FPS often has few definite rooms, or
the player moves between rooms very quickly). Sometimes the level name, or the
name of the player's character, is displayed at the top -- this is, again, not
vital information.

Ultimately, I think that information which the player is most likely to
consider in his choice of "what do I do next?" should go near the bottom of the
window. More decorative or general information, which the player can be
expected to use as a gauge of where he is in the game, can go toward the top.
Put another way, if the player might WANT to see it, put it at the top; if the
player NEEDS to see it, put it at the bottom.

--OKB (Bren...@aol.com) -- no relation to okblacke

"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown

Lucian P. Smith

unread,
May 26, 2001, 11:46:26 PM5/26/01
to
Walter Sandsquish (Sands...@aol.com) wrote in <6646733c.01052...@posting.google.com>:

: Sean T. Barrett (buz...@world.std.com) wrote:
: <<I agree that the status line certainly is comparable to the title
: bar of a window insofar as I generally never look at it. [...] If the
: status line is entirely irrelevant, sure, leave it at the top.>>
:
: If the status line is irrelevant (and most of the time, I think it is),
: why not leave it out alltogether?

I wouldn't say it's entirely irrelevant, but I would say that the
information there is absorbed at a much different *pace* by the player.
Or, at least by this player ;-)

When I'm active and involved in a game, I'm watching the latest text to
appear like a hawk, typing in new commands, and watching the results.

Then, when I get stuck, I take a break, sit back, look up the screen at
the last few text blocks, maybe glance at the status bar for an update
on my score, to see how far along I am. If I was reading a book, this
would be equivalent to me stopping, looking up at the chapter title,
maybe glancing to see how many more pages I had to go in the story.

The message is: If you put information in the status bar that they
player would need while they're involved in the story, they either
won't see it at all, or will only see it after they've 'disconnected'
from the game. Room name and score? Sure, put that in the chapter
title/page number area of the screen. Compass? Probably better at the
bottom. Ditto conversation options. (Exception: 'Once' (the Textfire
game) where whole *swaths* of conversation all took place in the status
bar, so that's where the player's attention was the entire time.)

The biggest offender of this that I can think of in recent memory is
"The Djinni Chronicles", which put the PC's 'Purpose' in the status
line. By the time I saw it, I had already disconnected from the
game--it let me down, and the rest of my playing time was somewhat
spoiled. Maybe if it was at the bottom, I'dve stayed connected to the
game longer, and would have enjoyed it more.

Someone should ask Don Woods if putting the status bar at the top was a
conscious decision, and if so, why he did it that way.

-Lucian

Andrew Plotkin

unread,
May 27, 2001, 12:12:10 AM5/27/01
to
Lucian P. Smith <lps...@rice.edu> wrote:

> Someone should ask Don Woods if putting the status bar at the top was a
> conscious decision, and if so, why he did it that way.

*Did* Don Woods put a status bar anywhere? I don't remember one in
Adventure, and the Fortran source for Dungeon didn't have a status bar
either.

I always thought it was invented as part of the Z-machine, for the
Zork (1) home computer release.

(Although the Scott Adams games had a top-side status window too, and
at approximately the same time -- I don't know which came first. Of
course the SA games put room description and exits in the status
window.)

Upon reading recent messages of this thread, I find that I am most
compelled by the human-factors argument for the traditional system:
the "active zone", where my eyes are focussed nearly all the time, is
the bottom edge of the screen/window. A supplementary information
zone, to which I refer occasionally, is at the top edge. Everything in
between is recent history.

A word processor doesn't have *quite* the same requirements, because
you edit text in random order. The active zone is often at the bottom
of the text, but sometimes in the middle, and when it's in the middle
you want to see context above and below the cursor. So you can't lock
the cursor to the bottom edge of the window. Once you're used to
roving up and down the middle of the window, it's sort of arbitrary
what information you lock to the top and bottom edges; I think the
status line has migrated to the bottom simply because modern GUIs put
menu bars and title bars at the top.

This doesn't address the question of whether a status bar is necessary
at all, in an IF game.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

* International election observers in '04...

Branko Collin

unread,
May 28, 2001, 11:09:42 AM5/28/01
to
On 27 May 2001 04:12:10 GMT, Andrew Plotkin <erky...@eblong.com>
wrote:

>(Although the Scott Adams games had a top-side status window too, and
>at approximately the same time -- I don't know which came first. Of
>course the SA games put room description and exits in the status
>window.)

IIRC, Scott Adam's games also had relatively concise descriptions, so
that you were looking at the top of the screen most of the time.

[...]


>This doesn't address the question of whether a status bar is necessary
>at all, in an IF game.

I can imagine a game where you have to play against the clock. You
would want to have all the information you could possibly need at the
same time available to you. In all other, it should be possible to
request status information using a command (score, health, look, etc.)
without being punished (for instance by the game considering it a turn
to request such information).

--
branko collin
col...@xs4all.nl

Branko Collin

unread,
May 28, 2001, 11:09:41 AM5/28/01
to
On Sat, 26 May 2001 05:46:31 GMT, buz...@world.std.com (Sean T
Barrett) wrote:
>Matthew W. Miller <mwmi...@columbus.rr.com> wrote:

>>The status line in most GUI programs, I think, is not comparable to the
>>status line of an IF game.
>
>Er... depends on the program. Heck, the status line in games like Doom
>are at the bottom of the screen

The logical place for status information to appear in a Doom-like game
would be the middle of the screen, comparable to the HUD in a fighter
plane, I think.

--
branko collin
col...@xs4all.nl

Carl Muckenhoupt

unread,
May 30, 2001, 5:40:39 PM5/30/01
to
It seems to me that the reasons for favoring the bottom as the location
for a status line might not apply to text adventures.

The information contained in the status line of a 3D game is typically
your supply of health, ammo, maybe mana or something. This is
information that the user wants to be kept aware of at all times, and
which is seldom communicated in any other way (although a very low health
might have effects on gameplay). Thus, it is desirable to keep it in the
same area of the screen that the user tends to look at the most. In a
landscape, this tends to be the ground.

In a text adventure, the status line typically contains your current
room, your score, the time number of turns you've taken, and maybe some
other game-specific datum like your blood pressure. Score and time are
typically not things that you need to be aware of at all times, and the
room and additional data usually have adequate notification in the main
window. Combined with the fact that the game is not occurring in real
time, this means that the user is not constantly glancing at the status
line, and it's just as well to keep it out of the way. At the top, it
serves the same function as the heading on a table.

But is this just clever rationalizing of habit? Well, when I played Zork
I for the first time, the status line was at the bottom. (This was on
the TRS-80 version published by Personal Computing.) Later Zorks put the
status line at the top. It's been a long time, but I seem to remember
the status line at the top seeming strange at first, but then seeming
natural once I got used to it. So I'd say it really doesn't make a great
deal of difference.

Carl Muckenhoupt

unread,
May 30, 2001, 5:44:29 PM5/30/01
to
In article <9epuqq$4ml$1...@news.panix.com>, erky...@eblong.com says...

>
> I think the
> status line has migrated to the bottom simply because modern GUIs put
> menu bars and title bars at the top.

Emacs had a status line at the bottom long before GUIs. But it could be
an aberration.

Carl Muckenhoupt

unread,
May 30, 2001, 5:53:02 PM5/30/01
to
In article <9epuqq$4ml$1...@news.panix.com>, erky...@eblong.com says...
> Lucian P. Smith <lps...@rice.edu> wrote:
>
> > Someone should ask Don Woods if putting the status bar at the top was a
> > conscious decision, and if so, why he did it that way.
>
> *Did* Don Woods put a status bar anywhere? I don't remember one in
> Adventure, and the Fortran source for Dungeon didn't have a status bar
> either.
>
> I always thought it was invented as part of the Z-machine, for the
> Zork (1) home computer release.

As mentioned elsewhere in this thread: the initial commercial release of
Zork I had a status line, but it was at the bottom.

Andrew Plotkin

unread,
May 30, 2001, 6:11:09 PM5/30/01
to
Carl Muckenhoupt <ca...@wurb.com> wrote:
> In article <9epuqq$4ml$1...@news.panix.com>, erky...@eblong.com says...
>>
>> *Did* Don Woods put a status bar anywhere? I don't remember one in
>> Adventure, and the Fortran source for Dungeon didn't have a status bar
>> either.
>>
>> I always thought it was invented as part of the Z-machine, for the
>> Zork (1) home computer release.

> As mentioned elsewhere in this thread: the initial commercial release of
> Zork I had a status line, but it was at the bottom.

I missed the mention in this thread. What year was that, and for what
platform?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

* Gore won the undervotes:
http://www.gopbi.com/partners/pbpost/news/election2000_pbgore.html

Andrew Plotkin

unread,
May 30, 2001, 6:12:10 PM5/30/01
to

Emacs is *always* an aberration. :-) But I still think that a text
adventure window and a text editor window have slightly different UI
constraints.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

Carl Muckenhoupt

unread,
May 30, 2001, 10:25:05 PM5/30/01
to
In article <9f3r5t$n8v$2...@news.panix.com>, erky...@eblong.com says...

>
> > As mentioned elsewhere in this thread: the initial commercial release of
> > Zork I had a status line, but it was at the bottom.
>
> I missed the mention in this thread. What year was that, and for what
> platform?

1979 or 1980, for the TRS-80 Model 1. It's the "Personal Software"
edition with the cover art featuring a muscular hero in a winged helmet.

Currently, my only evidence for this claim is childhood memories, but
I'm scouring the illegalware sites for a copy of that particular version.
I'm pretty sure that the versions of Zork II and III for the TRS-80 that
I played had the status line at the top.

Andrew Plotkin

unread,
May 30, 2001, 11:11:23 PM5/30/01
to
Carl Muckenhoupt <ca...@wurb.com> wrote:
> In article <9f3r5t$n8v$2...@news.panix.com>, erky...@eblong.com says...
>>
>> > As mentioned elsewhere in this thread: the initial commercial release of
>> > Zork I had a status line, but it was at the bottom.
>>
>> I missed the mention in this thread. What year was that, and for what
>> platform?

> 1979 or 1980, for the TRS-80 Model 1. It's the "Personal Software"
> edition with the cover art featuring a muscular hero in a winged helmet.

Hurm. I believe I had that release for the Apple 2 (I wrote Eduware
before, but Personal Software sounds more correct). The status line
was definitely on top in my copy.

> Currently, my only evidence for this claim is childhood memories, but
> I'm scouring the illegalware sites for a copy of that particular version.
> I'm pretty sure that the versions of Zork II and III for the TRS-80 that
> I played had the status line at the top.

This sounds like a difference between their Z-terp for the Apple and
TRS-80, which they later regularized.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

* It's not a vote until it's counted.

David Thornley

unread,
May 31, 2001, 11:23:27 AM5/31/01
to
In article <3b1267cb...@news.xs4all.nl>,

Branko Collin <col...@xs4all.nl> wrote:
>On 27 May 2001 04:12:10 GMT, Andrew Plotkin <erky...@eblong.com>
>wrote:
>
>>(Although the Scott Adams games had a top-side status window too, and
>>at approximately the same time -- I don't know which came first. Of
>>course the SA games put room description and exits in the status
>>window.)
>
>IIRC, Scott Adam's games also had relatively concise descriptions, so
>that you were looking at the top of the screen most of the time.
>
I had a problem with some games through not looking at the status line,
which (IIRC) showed the visible contents of the rooms. In some game(s),
you would light a match and the only effect would be that the status
area would briefly show the room contents.

>[...]
>>This doesn't address the question of whether a status bar is necessary
>>at all, in an IF game.
>
>I can imagine a game where you have to play against the clock.

Infocom's "Border Zone". There was at least one puzzle where you
had to keep an eye on the status bar. I wasn't really fond of that
game.

--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-

Tim Mann

unread,
May 31, 2001, 7:05:42 PM5/31/01
to
In article <MPG.157f758b4...@News.CIS.DFN.DE>,

Carl Muckenhoupt <ca...@wurb.com> wrote:
>In article <9f3r5t$n8v$2...@news.panix.com>, erky...@eblong.com says...
>>
>> > As mentioned elsewhere in this thread: the initial commercial release of
>> > Zork I had a status line, but it was at the bottom.
>>
>> I missed the mention in this thread. What year was that, and for what
>> platform?
>
>1979 or 1980, for the TRS-80 Model 1. It's the "Personal Software"
>edition with the cover art featuring a muscular hero in a winged helmet.
>
>Currently, my only evidence for this claim is childhood memories, ...

There's a copy on www.trs-80.com. I've temporarily put a screen shot of
it at http://www.tim-mann.org/trs80/zork1.gif for your amusement.

--Tim
--
Tim Mann tim....@compaq.com http://www.tim-mann.org
Compaq Computer Corporation, Systems Research Center, Palo Alto, CA

Reply all
Reply to author
Forward
0 new messages