A Bill of Author's Rights

28 views
Skip to first unread message

b_fe...@yahoo.com

unread,
May 22, 1998, 3:00:00 AM5/22/98
to

[Note: in case you didn't catch the post, Barbara Fernald was an April
Fool's joke that didn't work all that well. I'm using her account here
to post something reasonable this time, so it can be read without the
meta-knowledge of who posted it.]

Sometimes, you gotta break the rules.

This essay is dedicated to countering all of the rules in Graham
Nelson's excellent 'A Bill of Player's Rights', using examples from
successful games where possible. The point is not to say that Graham
was wrong, but to point out that a slavish adherence to the rules will
not always work in your favor.

And so, without further ado,...

A Bill of Author's Rights

1: To have the freedom to kill the player without warning.

With the magical command 'UNDO', there's no real reason the player
should whinge about being killed off, particularly if it's humorous.

2: To give horribly unclear hints.

This has a long and healthy tradition in the 'last lousy point' of many
games, beginning with the original 'Adventure'. As long as it's not
crucial to finishing the game, you can tantalize and frustrate your
fanatical players for hours with appropriate obscure hints.

3: To require knowledge from past lives.

Again--if 'UNDO' and 'save/restore' are parts of the system, why not
assume your players are going to use it? It is certainly possible to
design a game you can play straight through without ever saving your
game, but is by no means necessary. The interactive experience that the
player traverses will explore a greater plot-space than the game
protagonist could logically encounter--why not take advantage of this
fact? In fact, the game may be more meaningful to the player if they
know the wrong turns they could take. The best way to clue a player in
to the best course of action may well be by killing them off a few
times.

4: To require knowledge of future events.

If a player can logically close off an avenue otherwise available to
them, let them. So Far did it, why can't you? Again, the experience
of the player and the experience of the protagonist do not necessarily
have to overlap exactly.

5: To close off the game without warning.

This is really Right #4, slightly restated (which, in turn, is a slight
restatement of Right #3). It is perfectly valid for an author to close
off the game if the game logic dictates such. Perhaps, by requiring the
Japanese paper wall the player can destroy early on, the author wishes
to make a statement against random acts of destruction.

6: To require the player to do unlikely things.

Granted, this would not be appropriate in many games. However, the
avenue should remain open to the intrepid author, should they choose
this route. Nord and Burt, to take an extreme example, would not be the
game that it is without requiring the player to perform various and
sundry rather unlikely activities.

7: To require boring activities for the sake of it.

Boredom is a force like any other, and should be able to be applied by
the author to judicious effect. One possibile use of boredom is to
encourage the player to seek out alternate methods to solve a puzzle.
Putting in a maze that has a way to bypass it would be an example of
this (and was used in such games as Leather Goddesses and Tryst of Fate)

8: To only allow certain phrasings.

Nuance is important, and sometimes the only way to ensure that the
player has the right idea is to only allow certain verbs or phrasings.
For example, if the player is standing at the top of a cliff, it makes
sense to assume the player wants to scramble down the cliff if they type
'down', and wants to jump off if they type 'jump', and not to assume
both commands mean the same thing.

9: To disallow certain synonyms.

In a game where there is a well-defined protagonist, that character
might not be expected to refer to some things as others might. In
'Suspended', for example, it would be silly to allow Waldo refer to a
'green fromitz board' and Iris refer to a 'broken fromitz board',
although both adjectives may be true. See also Right #16 (requiring
cultural knowledge), below.

10: To circumvent the parser if need be.

The parser is an amazing convenience, and should be embraced almost
always, but sometimes, it's too sophisticated for its own good.
Certainly for games like 'Freefall', 'Robots', and the latter bit of
'Sylenius Mysterium', a full parser would be needlessly complex. But
taking out the conversation verbs in 'Spider and Web' served that game
well, and let the player focus on more important aspects of the game.

11: To disallow freedom of action.

Spider and Web. Need I say more?

12: To make aspects of the game depend on luck.

Again, the miracle of 'Undo' and 'Save/restore' works to your advantage
here--why not use it? Some things in life *are* based on luck, and you
may wish to reflect this in your game. Multiple, random endings to
'Spider and Web' would have been a valid choice there, I think, even if
the protagonist died in some of them. Sometimes you get breaks, and
sometimes you don't.

13: To make obscure problems which might never be understood.

In real life, do you always understand why something you did worked out
in the end? Of course not. A good mystery can be enjoyed, and
sometimes a mysterious solution is even better than a mysterious puzzle.
The final move in 'So Far' is a decent example of this--the different
responses seem to indicate that one is better than the other, but why
this is so is left dramatically unclear. It is up to the reader to
puzzle out the reason--which they are not guaranteed to be able to do.

14: To give the player many red herrings.

There are many reasons you might wish to do this--perhaps you want the
player to *not* pick up everything that's nailed down, and to actually
think about what they might want to carry with them, instead. Perhaps
you simply want to increase the realism of the setting. If your puzzles
don't depend on carrying random items around everywhere, (or, indeed, if
you are shooting for 'puzzle-less' IF), red herrings are entirely
reasonable.

15: To give unreasonable explanations for impossible events.

People are not reasonable all the time. You might wish to simulate the
particuar unreasonableness of a player-character by having him refuse to
do things some times. Likewise, sometimes trying to come up with some
reason why you can't do something ends up sounding more hackneyed than a
simple, "You can't do that." Disallowing normal conversation in 'Spider
and Web' is another example of an arbitrary refusal that nonetheless
works for the game.

16: To require specific cultural knowledge.

Particularly in games with a well-defined protagonist, certain bits of
cultural information can and shoot be expected of the player. If you
want to be nice, you can include a note like that in 'I-0' in response
to certain british-isms (try 'EXAMINE BOOT' in that game), but even this
is not strictly necessary. As that note says, the player should do
their best to get into character. [This would, incidentally, be an
excellent place to include cross-cultural responses to the query 'what
is ____?' without sacrificing protagonist consistency.]

17: To keep the player in the dark as to how far into the game they
are.

How many times, when reading a book, have you glanced at the pages
remaining to get, essentially, spoiler information? "Ah, the mystery
seems to be solved, but there's still half the book left, so there must
be new twists!" "Only five pages left! This must be the final showdown
between good and evil!" In IF, we are given the unique opportunity to
hide this information from the player, which can be used to good effect.
Consider how the dynamic in 'Anchorhead' might have changed if, for
example, the final episode has simply been named, "Day X" instead of
"The Final Day". (Either is, of course, a valid choice, but it should
be an authorial choice, and not a requirement to pick one over the
other.)


In conclusion, although Graham's rules are indeed usually valid, there does
come a point in some instances where the rules must be broken if your work
is to acheive its highest potential.


Later,

Barb

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading

Paul A Krueger

unread,
May 23, 1998, 3:00:00 AM5/23/98
to

b_fe...@yahoo.com wrote in message <6k52n7$6di$1...@nnrp1.dejanews.com>...


> A Bill of Author's Rights
>
>1: To have the freedom to kill the player without warning.
>
>With the magical command 'UNDO', there's no real reason the player
>should whinge about being killed off, particularly if it's humorous.
>

This is the only one I disagree with, only because not all interpreters have
undo built in. I know that most of the games on the Masterpieces CD don't.
Can you imagine playing MST3K without undo? Well, when I was using the AGT
version I had to, and it was annoying even though it *was* funny. Besides,
what if undo doesn't immediately solve the problem? Yeah, I know we should
save but...

Weird Beard
weird...@prodigy.net

Ben

unread,
May 24, 1998, 3:00:00 AM5/24/98
to

In article <6k6oir$36b0$1...@newssvr04-int.news.prodigy.com>, "Paul A

Krueger" <WEIRD...@prodigy.net> wrote:
> This is the only one I disagree with, only because not all interpreters have
> undo built in. I know that most of the games on the Masterpieces CD don't.
> Can you imagine playing MST3K without undo? Well, when I was using the AGT
> version I had to, and it was annoying even though it *was* funny. Besides,
> what if undo doesn't immediately solve the problem? Yeah, I know we should
> save but...


Yep, and in a game like Jigsaw, this is certainly the case...

warp back to disc room, NE, *you have wrecked history*...
"undo", OOPS you're in the disc room and history is still wrecked! Hope
you saved!

-Ben

--
bhi...@san.rr.com
http://members.tripod.com/~tunnels/

Dan Shiovitz

unread,
May 25, 1998, 3:00:00 AM5/25/98
to

In article <bhines-2405...@ppp127-85.3com.cifnet.com>,
Ben <bhi...@san.rr.com> wrote:
[..]

>Yep, and in a game like Jigsaw, this is certainly the case...
>
>warp back to disc room, NE, *you have wrecked history*...
>"undo", OOPS you're in the disc room and history is still wrecked! Hope
>you saved!

..but only because you're using a hopelessly out-of-date VM that only
supports single-move undo.

>-Ben
--
(Dan Shiovitz) (d...@cs.wisc.edu) (look, I have a new e-mail address)
(http://www.cs.wisc.edu/~dbs) (and a new web page also)
(the content, of course, is the same)

Ben

unread,
May 26, 1998, 3:00:00 AM5/26/98
to

In article <6kar1p$7...@spool.cs.wisc.edu>, d...@mozzarella.cs.wisc.edu (Dan

Shiovitz) wrote:
>
> ..but only because you're using a hopelessly out-of-date VM that only
> supports single-move undo.
>

.. If March 16, 1998 is "hopelessly out of date". (I use MaxZip 1.7.5)

Take that one up with Plotkin.

Do most interpreters support multiple undo? I was under the impression
that it was standard practice not to. It certainly would not be
technically difficult.

Andrew Plotkin

unread,
May 26, 1998, 3:00:00 AM5/26/98
to

Ben (bhi...@san.rr.com) wrote:
> In article <6kar1p$7...@spool.cs.wisc.edu>, d...@mozzarella.cs.wisc.edu (Dan
> Shiovitz) wrote:
> >
> > ..but only because you're using a hopelessly out-of-date VM that only
> > supports single-move undo.
> >

> .. If March 16, 1998 is "hopelessly out of date". (I use MaxZip 1.7.5)

> Take that one up with Plotkin.

The *intepreter* is recent, the VM is more than a decade old. :)

There was a long debate about multiple undo in the Z-machine. I'm sure
dejanews has it. I took the (radical) position that the spec could
probably be read as supporting multiple undo; but it would probably be
more correct to say that the spec could be *extended* to support multiple
undo, in a fully backwards-compatible way.

Note: Frotz's multiple-undo behavior is not relevant to this discussion,
because it's entirely outside the Z-spec. Not legal or illegal; but
entirely outside it. (Unless you count the author's expectation of the
player's level of control as part of the spec, but that's a much ickier
philosophical mess.)

--Z
--

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

L. Ross Raszewski

unread,
May 26, 1998, 3:00:00 AM5/26/98
to

In article <erkyrathE...@netcom.com>,

erky...@netcom.com (Andrew Plotkin) wrote:
>
> The *intepreter* is recent, the VM is more than a decade old. :)
>
> There was a long debate about multiple undo in the Z-machine. I'm sure
> dejanews has it. I took the (radical) position that the spec could
> probably be read as supporting multiple undo; but it would probably be
> more correct to say that the spec could be *extended* to support multiple
> undo, in a fully backwards-compatible way.
>
> Note: Frotz's multiple-undo behavior is not relevant to this discussion,
> because it's entirely outside the Z-spec. Not legal or illegal; but
> entirely outside it. (Unless you count the author's expectation of the
> player's level of control as part of the spec, but that's a much ickier
> philosophical mess.)
>

In either case, I think it'snow _generally_ agreed that Save, Restore, Undo,
and the like are all "interface_ features, rather than _game_ features, and
it's in pretty poor taste to require that a player use them in order to solve
a puzzle.

Andrew Plotkin

unread,
May 26, 1998, 3:00:00 AM5/26/98
to

L. Ross Raszewski (rras...@hotmail.com) wrote:

> In either case, I think it'snow _generally_ agreed that Save, Restore, Undo,
> and the like are all "interface_ features, rather than _game_ features, and
> it's in pretty poor taste to require that a player use them in order to solve
> a puzzle.

Mmm, maybe this is true of puzzles.

I don't think it's true of entire games.

You can write a game with the knowledge that undo is available. It makes
a difference, even if it's just for the player's "wandering around
trying-silly-things" mode. (Which is at least as important as solving
puzzles.)

And, similarly, you can write a game with the knowledge that multi-level
undo is available, as opposed to single undo.

Both are the kind of things I consider at all levels of game design.
Maybe I'm the same kind of fanatic that considers fone and page layout
when writing the text of a novel. But I think details are important.

L. Ross Raszewski

unread,
May 27, 1998, 3:00:00 AM5/27/98
to

In article <erkyrathE...@netcom.com>,
erky...@netcom.com (Andrew Plotkin) wrote:
>
> I don't think it's true of entire games.
>
> You can write a game with the knowledge that undo is available. It makes
> a difference, even if it's just for the player's "wandering around
> trying-silly-things" mode. (Which is at least as important as solving
> puzzles.)
>
> And, similarly, you can write a game with the knowledge that multi-level
> undo is available, as opposed to single undo.


Hm... perhaps I could have been more specific. It's one of the things I
considered when I was trying to think up a "players bill of responsibilities"
as corrolary to the Player's bill of rights. Something that's easy to
misinterpret.

You certainly should _consider_ the interface features, but it's low (IMHO,
probably) to _require_ exploitation of them.
For example, it is wrong to make a puzzle that must be solved by random
guessing. However, there is nothing wrong with making a puzzle that _can_ be
solved by random guessing.
Likewise, you may well write the game in a construct that presumes the player
has "undo" available to them, however, any game in which the only reasonable
way to "win" (or whatever it is one does in your games :-) is to use "undo" is
wrong.
To extend it again to the player's bill of rights, it is flat out wrong to
require the player have past-life experience in orderto get ahead, but there
is nothing wrong if a players past-life expereince does prove useful, so long
as they could have gotten by without it (eg. so logn as the player can defuse
the bomb with the code found in the basement, it doesn't matter that they in
fact did defuse the bomb by entering random codes, getting blown up, and
trying again until they found one that works.)

Andrew Plotkin

unread,
May 27, 1998, 3:00:00 AM5/27/98
to

L. Ross Raszewski (rras...@hotmail.com) wrote:

> You certainly should _consider_ the interface features, but it's low (IMHO,
> probably) to _require_ exploitation of them.

> [...]


> Likewise, you may well write the game in a construct that presumes the player
> has "undo" available to them, however, any game in which the only reasonable
> way to "win" (or whatever it is one does in your games :-) is to use "undo" is
> wrong.

This sounds great when you put it like that, but it gets awfully fuzzy in
practice. If I write a game where most players will try silly things,
often fatally, and then "undo" them -- is that presuming that "undo" is
available? What if a lot of the fun of the game is doing that kind of
thing? What if all of the fun of the game is doing that kind of thing,
and there is no winning state per se?

It's important to note that I see *no* hard boundary between puzzles,
storytelling, and just fooling around.

Anyway, if you're including "restore" and "restart" as interface features
-- again, that hard categorization -- the situation becomes highly
nonintuitive. Many, many games cannot be reasonably solved in a single
session. If only because you can't stay awake that long.

Trying to make rules about this stuff is like trying to nail jelly to a
Bach fugue.

Charles Gerlach

unread,
May 27, 1998, 3:00:00 AM5/27/98
to

L. Ross Raszewski wrote:

> For example, it is wrong to make a puzzle that must be solved by random
> guessing. However, there is nothing wrong with making a puzzle that _can_ be
> solved by random guessing.

<RANT ON>

7th guest and 11th hour were just re-released in the bargain bin,
so I picked them up.

I solved one of the puzzles in 7th guest (the one where you had to
get from the lower left to the upper right walking on different colored
tiles and watching the tiles fall away behind you).

Since I hadn't understood what I had done, I went back and did it
again.

It *still* makes no sense whatsoever. The "goal" as stated by the
annoying voice is "...can you get from A to B?" And the
answer is yes-- you can get to the exit arrow without difficulty
almost every time. But when you get there, the voice says you
didn't solve it and resets it. No clue as to why what you did was
wrong.

Eventually I started messing around, taking circuitous paths to the
exit, and one of them worked. I looked at the path I had just taken
and saw no possible rule that had been followed throughout the
course of the path.

SO, unless you want me to come to your house and shoot out your
porch light, I would suggest that any puzzle that *can* be solved
by guessing should be possible to figure out ex post facto.

(For instance, I will admit (to my shame) that I got the circuit
breakers turned back on in "Losing your grip" via multiple undos.
Once I had done it that way, I was dissatisfied, and looked
around until it hit me where the clue for the ordering was.
Perfectly satisfactory puzzle that I circumvented.)

<RANT OFF>

<MINOR RANT BACK ON>

How in the blazes did 7th guest stay such a hot seller for so long?
Bad acting, bad acting replaced/re-written with bad voice-overs that
don't even come close to matching the scene, no concept of which
direction doors should lead based on the floor-plan, "Feeling
lo-o-o-o-onely?"-- the list of things that annoyed me can go on for
pages.

I went in not expecting much, and came out with even less.

<MINOR RANT OFF>

--
Charles Gerlach doesn't speak for Northwestern. Surprise, surprise.

Lucian Paul Smith

unread,
May 27, 1998, 3:00:00 AM5/27/98
to

L. Ross Raszewski (rras...@hotmail.com) wrote:

: You certainly should _consider_ the interface features, but it's low (IMHO,
: probably) to _require_ exploitation of them.

[Apologies if this gets posted twice; dunno what happened to the first
one, but it looks like it didn't go through.]

I'm not sure but if this objection is more philosophical than
experiential. If it's experiential, why do authors break this rule all
the time, and why don't we come down harder on them if they do? Take
'Losing Your Grip' as a modern example, and 'Trinity' as a classic one.
In both, it is theoretically possible to get through the game in one
sitting, but everyone knows that this won't happen. And yet, these games
remain fun. Both resort to other methods to make replaying it not quite
such a chore--Trinity by the relatively tiny nature of the areas beyond
the mushrooms, and Grip by not randomizing the clocks (which eliminates
having to re-play the most potentially tedious section of the first fit).

: To extend it again to the player's bill of rights, it is flat out wrong to


: require the player have past-life experience in orderto get ahead, but there
: is nothing wrong if a players past-life expereince does prove useful, so long
: as they could have gotten by without it (eg. so logn as the player can defuse

: the bomb with the code found in the basement, it doesn't matter that they in


: fact did defuse the bomb by entering random codes, getting blown up, and
: trying again until they found one that works.)

'Wrong' is too strong a word to use here, I think. Not all situations are
as clear-cut as the one you describe, though I do agree that in that
example, adherence to Graham's laws would be important. 'So Far' is
another example of a game you couldn't be expected to play through in one
sitting without getting something wrong, and using that information to
help you in your next game. It's considered sporting to *tell* the player
beforehand, of course, whether through the accessory materials or through
game design (making it obvious from the start that this is that kind of
game). A game that leads you down the primrose path for 3/4 of the game
and then suddenly switches gears on you, requiring saved games, is cruel
(Actually, my solitary beef with Spider and Web is that it can look like
it does this to you. If you haven't been saving your game, you suddenly
get to a point where you might decide you want to restore, without enough
warning.)

Does Trinity have a game design flaw because it requires knowledge of past
lives? I don't think so, actually. Does it have a flaw in the narrative?
Maybe. But if you think about it, this perspective does shed new light on
the whole loop aspect of the game,...

My feeling is that we tend to see flaws in games that would be flaws in a
traditional narrative. I also think we need to start moving away from
this. It's obviously impossible for the hero of the story to fail to keep
the train from crashing, then back up and try again, this time succeeding.

But actually, this makes me think of something else--a traditional
narrative story is to have the hero fail at something, grow, then succeed
later at a similar problem. Maybe this is the story we play out in our
games.

-Lucian

Lucian Paul Smith

unread,
May 27, 1998, 3:00:00 AM5/27/98
to

L. Ross Raszewski (rras...@hotmail.com) wrote:

: Hm... perhaps I could have been more specific. It's one of the things I


: considered when I was trying to think up a "players bill of responsibilities"
: as corrolary to the Player's bill of rights. Something that's easy to
: misinterpret.

: You certainly should _consider_ the interface features, but it's low (IMHO,


: probably) to _require_ exploitation of them.

But why do authors violate this rule pretty consistently, and everyone
only half-heartedly complains? It seems to me that it might be an
argument that's mostly philosophical, instead of something that actually
negatively affects gameplay. To pick a modern example: Losing Your Grip
requires you to use save/restore (or TADS multiple undo). A classic
example: Trinity. Both, however, made allowances in other ways for this
fact. In Trinity, the sub-sections were pretty small, and, as such, were
relatively easy to replay. In Grip, the clocks were not randomized, but
remained constant over saved games and even restarts, so the most tedious
section of the first fit only needed to be played through once, since it
was virtually guaranteed that you would be coming back.

The same could be said of 'So Far', for that matter. It's considered
sporting to inform the player beforehand what kind of game they are
playing (the zarfian 'cruelness' scale), but even that isn't necessary;
usually the player figures it out pretty quick. Well, let me modify
that--it's sporting to tell the player the cruelness level beforehand,
whether through the auxilliary materials, or by game design. (A game that
led the player down the primrose path for 3/4 of the game, then suddenly
switched gears and became 'cruel' is mean. My single gripe with Spider
and Web was that it seemed like it reached this point a little early, and
the player might not have saved their game recently.)

: To extend it again to the player's bill of rights, it is flat out wrong to
: require the player have past-life experience in orderto get ahead, but there
: is nothing wrong if a players past-life expereince does prove useful, so long
: as they could have gotten by without it (eg. so logn as the player can defuse
: the bomb with the code found in the basement, it doesn't matter that they in
: fact did defuse the bomb by entering random codes, getting blown up, and
: trying again until they found one that works.)

But it's not always so clear-cut. Your example is clearly one where
Graham's rules should be followed. But did Trinity suffer as a game
because it required you to know what was beyond each mushroom before you
went in? I don't think so; not quite. Did it suffer as a narrative?
Maybe. (But maybe not--it certainly casts an interesting light on the
whole loop aspect of the game.)

The more I think about it, the more I believe our strongest objections to
this kind of thing stem from our preconceptions about books--certainly,
the protagonist of a book does not have the luxury of failing to stop the
train before it crashes, learning from it, and going back to save the same
train a second time.

But now I'm thinking again--this actually *is* a common theme in
literature. The hero fails, the hero grows, the hero is presented with a
similar problem and this time succeeds. Maybe it's this kind of story we
replay in our games.

-Lucian

Steven Posey

unread,
May 27, 1998, 3:00:00 AM5/27/98
to

On Wed, 27 May 1998 05:40:32 GMT, erky...@netcom.com (Andrew Plotkin) wrote:

>Trying to make rules about this stuff is like trying to nail jelly to a
>Bach fugue.
>

As a music major from Furman University I'd really like to know what THAT means!!! ;-)

Steven

Ben

unread,
May 27, 1998, 3:00:00 AM5/27/98
to

In article <6kh6rd$sga$1...@joe.rice.edu>, lps...@rice.edu (Lucian Paul
Smith) wrote:

> The more I think about it, the more I believe our strongest objections to
> this kind of thing stem from our preconceptions about books--certainly,
> the protagonist of a book does not have the luxury of failing to stop the
> train before it crashes, learning from it, and going back to save the same
> train a second time.

Books? Try life! Its not "realistic" to be able to undo. In REAL LIFE you
don't go into a situation knowing what is going to happen, or doing
something foolish because you know you can undo. I'll say the word... It
breaks mimesis.

Not that I am against undo, mind you. :) The point of good IF, IMO, is to
have fun. Trinity with no save/restore/undo would NOT be fun AT ALL.

Michael Straight

unread,
May 27, 1998, 3:00:00 AM5/27/98
to

On 27 May 1998, Lucian Paul Smith wrote:

> But it's not always so clear-cut. Your example is clearly one where
> Graham's rules should be followed. But did Trinity suffer as a game
> because it required you to know what was beyond each mushroom before you
> went in? I don't think so; not quite. Did it suffer as a narrative?
> Maybe. (But maybe not--it certainly casts an interesting light on the
> whole loop aspect of the game.)
>

> The more I think about it, the more I believe our strongest objections to
> this kind of thing stem from our preconceptions about books--certainly,
> the protagonist of a book does not have the luxury of failing to stop the
> train before it crashes, learning from it, and going back to save the same
> train a second time.
>

> But now I'm thinking again--this actually *is* a common theme in
> literature. The hero fails, the hero grows, the hero is presented with a
> similar problem and this time succeeds. Maybe it's this kind of story we
> replay in our games.

I think one of the other reasons we don't balk so much at saving and
restoring and undoing is that the player is not the protagonist. The
protagonist is merely a character in the story, the viewpoint character.

The player is more like a cross between a reader and an author. When I
play I-0, it's not that Tracy has precognition and is able to look ahead
to see what will happen if she hitchhikes, but rather me as the
reader/author playing with different possible actions and plots until I
hit upon one that "works." Playing IF is often more like reading a story
and trying to guess what will happen next than it is a simulation of the
protagonist's experiences.

That being said, I think one of the most immersive games I've played
recently was "Babel," partly because of the writing, but also at least in
part because it is "kind" and I didn't have the urge to save, restore, or
even undo for the first half of the game.

SMTIRCAHIAGEHLT


George Caswell

unread,
May 27, 1998, 3:00:00 AM5/27/98
to

On Wed, 27 May 1998, Ben wrote:

> In article <6kh6rd$sga$1...@joe.rice.edu>, lps...@rice.edu (Lucian Paul
> Smith) wrote:
>

> > The more I think about it, the more I believe our strongest objections to
> > this kind of thing stem from our preconceptions about books--certainly,
> > the protagonist of a book does not have the luxury of failing to stop the
> > train before it crashes, learning from it, and going back to save the same
> > train a second time.
>

> Books? Try life! Its not "realistic" to be able to undo. In REAL LIFE you
> don't go into a situation knowing what is going to happen, or doing
> something foolish because you know you can undo. I'll say the word... It
> breaks mimesis.
>

Ah, screw mimesis. (didn't see -that- one in mimesis.z5...) The thing
is, it's a game. For starters, the player's never going to be as well
equipped to deal with the situation as the real character would be, the
player can't always solve the problem using the (often quite reasonable)
solutions in their heads... And it's fiction, it doesn't need to be
perfectly realistic to be good fiction. Anyone who tells you differently
just worries too much. If the player didn't -need- to try some different
things to be able to solve the problems in the game, if the player didn't
occasionally get into a bind they couldn't get out of, or get killed
altogether, there'd be no challenge, and challenge is the whole point in
interactive fiction.

---GEC


J. Holder

unread,
May 27, 1998, 3:00:00 AM5/27/98
to

Thus spake Dan Shiovitz <d...@mozzarella.cs.wisc.edu>:
: ..but only because you're using a hopelessly out-of-date VM that only
: supports single-move undo.

Hmmmph. Phhhhhpt!

--
John Holder (jho...@frii.com) http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/

Joe Mason

unread,
May 27, 1998, 3:00:00 AM5/27/98
to

And as a jelly major, I'd like to know too!!!

Joe

Giles Boutel

unread,
May 28, 1998, 3:00:00 AM5/28/98
to


Joe Mason <jcm...@execulink.com> wrote in article
<356CB2A6...@execulink.com>...

It's widely known that jellies and fugues occupy different dimensions. The
Jelly Dimension is one where structure breaks down into amorphosity. In
contrast, the Fugual Dimension is one where structure is paramount,
governed in a draconian manner by the laws of reversal, inversion and
general cleverdickery. This being the case, it is impossible for these two
items to mesh in any way, as this would violate their fundamental natures
and create a catastrophic rift in the fabric of the universe.

There are, of course, certain occasions and locations when the strict
nature of dimensional laws breaks down. One famous Quantum Chef, having
succesfully translated an ancient recipe of the NeeNocker tribe which
mentioned such a time and place, attempted to violate the laws of Jelly
amorphosity and was rewarded by the arrival of a fiendish tune that
continually played backwards and forwards (often simultaneously) in his
head, until he went quite mad.

The Bach reference is, alas, completely superfluous to the simile.

Hope this helps

-Giles

HarryH

unread,
May 28, 1998, 3:00:00 AM5/28/98
to

In article <6kh6rd$sga$1...@joe.rice.edu>, lps...@rice.edu says...

>But now I'm thinking again--this actually *is* a common theme in
>literature. The hero fails, the hero grows, the hero is presented with a
>similar problem and this time succeeds. Maybe it's this kind of story we
>replay in our games.

Unfortunately, we aren't heroes. I'm sorry, but given the choice of heroic
deeds and easy cheat, most of us would cheat. It's kind of difficult to put a
hard puzzle in IF without someone saying that the puzzle isn't fair. I mean,
it's OBVIOUS that you should stab yourself on the right side because your
heart is located on the left, right? :)

-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant


L. Ross Raszewski

unread,
May 28, 1998, 3:00:00 AM5/28/98
to

In article <Pine.OSF.3.96.980527...@wpi.WPI.EDU>,
George Caswell <timb...@wpi.edu> wrote:

> Ah, screw mimesis. (didn't see -that- one in mimesis.z5...) The thing

Play in lewd mode :-)

Iain Merrick

unread,
May 28, 1998, 3:00:00 AM5/28/98
to

Ben wrote:

> In article <6kh6rd$sga$1...@joe.rice.edu>, lps...@rice.edu (Lucian Paul
> Smith) wrote:
>
> > The more I think about it, the more I believe our strongest objections to
> > this kind of thing stem from our preconceptions about books--certainly,
> > the protagonist of a book does not have the luxury of failing to stop the
> > train before it crashes, learning from it, and going back to save the same
> > train a second time.
>
> Books? Try life! Its not "realistic" to be able to undo. In REAL LIFE you
> don't go into a situation knowing what is going to happen, or doing
> something foolish because you know you can undo. I'll say the word... It
> breaks mimesis.
>

> Not that I am against undo, mind you. :) The point of good IF, IMO, is to
> have fun. Trinity with no save/restore/undo would NOT be fun AT ALL.

Hmmm...

------

> SQUEEZE POD

As you crush the seed pod, a pungent oily substance drips between your
fingers. You suddenly realise that this is just what you need to solve
the Deeply Symbolic puzzle you passed earlier, but that by crushing the
pod here you've gone and mucked things up.

> UNDO

That's not how life works.

> DAMN AND BLAST

Real adventurers do not use such language.

> RESTORE

That's not how life works.

> QUIT

That's not how life works.

> [CTRL-ALT-DEL]

That's not how life works.

> [Reaches for power switch; pauses, warily...]

------

...you're right; _nobody_ would be _that_ cruel.

Steven Posey

unread,
May 28, 1998, 3:00:00 AM5/28/98
to

On 28 May 1998 04:11:19 GMT, "Giles Boutel" <Giles....@wcc.govt.nz> wrote:

>It's widely known that jellies and fugues occupy different dimensions. The
>Jelly Dimension is one where structure breaks down into amorphosity. In
>contrast, the Fugual Dimension is one where structure is paramount,
>governed in a draconian manner by the laws of reversal, inversion and
>general cleverdickery. This being the case, it is impossible for these two
>items to mesh in any way, as this would violate their fundamental natures
>and create a catastrophic rift in the fabric of the universe.

Oh, I get it now. Having written fugues, I should have immediately seen the difference. Maybe if I
could write jellies, I'd have seen it sooner ;-[)
Steven

Den of Iniquity

unread,
May 28, 1998, 3:00:00 AM5/28/98
to

On 28 May 1998, Giles Boutel wrote:

>There are, of course, certain occasions and locations when the strict
>nature of dimensional laws breaks down. One famous Quantum Chef, having
>succesfully translated an ancient recipe of the NeeNocker tribe which
>mentioned such a time and place, attempted to violate the laws of Jelly
>amorphosity and was rewarded by the arrival of a fiendish tune that
>continually played backwards and forwards (often simultaneously) in his
>head, until he went quite mad.

And thus the Turkish Delight was born.

--
Den


Ola Sverre Bauge

unread,
May 28, 1998, 3:00:00 AM5/28/98
to

George Caswell wrote...

> Ah, screw mimesis. (didn't see -that- one in mimesis.z5...)

You need to play it in LEWD mode to see that.

Ola Sverre Bauge
o...@bu.telia.no
http://w1.2327.telia.com/~u232700165

Dennis Matheson

unread,
May 28, 1998, 3:00:00 AM5/28/98
to

Giles Boutel wrote:
>
> Joe Mason <jcm...@execulink.com> wrote in article
> <356CB2A6...@execulink.com>...
> > Steven Posey wrote:
> > >
> > > On Wed, 27 May 1998 05:40:32 GMT, erky...@netcom.com (Andrew Plotkin)
> wrote:
> > >
> > > >Trying to make rules about this stuff is like trying to nail jelly to
> a
> > > >Bach fugue.
> > > >
> > > As a music major from Furman University I'd really like to know what
> THAT means!!! ;-)
> >
> > And as a jelly major, I'd like to know too!!!
>
> It's widely known that jellies and fugues occupy different dimensions. The
> Jelly Dimension is one where structure breaks down into amorphosity. In
> contrast, the Fugual Dimension is one where structure is paramount,
> governed in a draconian manner by the laws of reversal, inversion and
> general cleverdickery. This being the case, it is impossible for these two
> items to mesh in any way, as this would violate their fundamental natures
> and create a catastrophic rift in the fabric of the universe.
>
> There are, of course, certain occasions and locations when the strict
> nature of dimensional laws breaks down. One famous Quantum Chef, having
> succesfully translated an ancient recipe of the NeeNocker tribe which
> mentioned such a time and place, attempted to violate the laws of Jelly
> amorphosity and was rewarded by the arrival of a fiendish tune that
> continually played backwards and forwards (often simultaneously) in his
> head, until he went quite mad.
>
> The Bach reference is, alas, completely superfluous to the simile.
>
> Hope this helps
>
> -Giles

Hmmm... For a moment there I thought I was on alt.fan.hofstadter.
--
"You can't run away forever, but there's nothing wrong
with getting a good head start" --- Jim Steinman

Dennis Matheson --- Dennis....@delta-air.com
--- http://home.earthlink.net/~tanstaafl

Jonadab

unread,
May 29, 1998, 3:00:00 AM5/29/98
to

> > The more I think about it, the more I believe our strongest objections
to
> > this kind of thing stem from our preconceptions about books--certainly,
> > the protagonist of a book does not have the luxury of failing to stop
the
> > train before it crashes, learning from it, and going back to save the
same
> > train a second time.
>
> Books? Try life! Its not "realistic" to be able to undo. In REAL LIFE you
> don't go into a situation knowing what is going to happen, or doing
> something foolish because you know you can undo. I'll say the word... It
> breaks mimesis.
>
> Not that I am against undo, mind you. :) The point of good IF, IMO, is to
> have fun. Trinity with no save/restore/undo would NOT be fun AT ALL.
>

Actually, I'm not against save & restore or undo, but I am against multiple
undo. I think that goes a step too far in making the game too easy, and
I'm going to attempt to disable it in my game, Diary of a Text Adventurer.


--
From 501 uses for peanut butter:
200. Design an aerobic workout fitness machine called the
PB2000 that uses peanut butter in its hydrolic systems
and enables the user to "burn the equivalent of 2000
grams of peanut butter in a 45-minute workout!" Hold
an infomercial featuring a dozen extremely thin and
scantily clad models (most of them female) eating loads
of peanut butter while exercising on the PB2000.
Explain that the PB2000 folds nicely and fits in a
standard-size breifcase. Cut me in on the
profits.

My Current Quote: "I'm sorry, sir, but we're all out of Beanie
Babies."

"I" /\ \I /\ I\ /\ I) /\ I) I) 1 /_ II "I" \I [" "I"
\I \/ I\ II I/ II I) \a I) I\ 1 \/ TT I o I\ [_ I

L. Ross Raszewski

unread,
May 29, 1998, 3:00:00 AM5/29/98
to

In article <01bd8ad2$2ba15300$08118fd1@jonadab>,

"Jonadab" <jon...@bright.net> wrote:
>
> Actually, I'm not against save & restore or undo, but I am against multiple
> undo. I think that goes a step too far in making the game too easy, and
> I'm going to attempt to disable it in my game, Diary of a Text Adventurer.

First time I do something that puts the game in an unwinnable state and I
can't multiple-undo out of it, I'll very probably quit the game and never come
back.

Inconveniencing the player for the sake of making the game hard is not my idea
of a good idea.


If you want to make the game realistic, write a loader that deletes the game
file as soon as the player dies.

Or better yet, write a loader that electrocutes the player as soon as the
character dies.

Lucian Paul Smith

unread,
May 29, 1998, 3:00:00 AM5/29/98
to

In article <01bd8ad2$2ba15300$08118fd1@jonadab>, "Jonadab"
<jon...@bright.net> wrote:
>
> Actually, I'm not against save & restore or undo, but I am against multiple
> undo. I think that goes a step too far in making the game too easy, and
> I'm going to attempt to disable it in my game, Diary of a Text Adventurer.

Well, you can't in Inform; it's part of WinFrotz, not your game. Although
you could probably do that in TADS.

But disabling it would be a mistake, anyway. Multiple undos are a
convenience to the player, and it should be a player choice, not an author
one.

IMHO, of course.

-Lucian

George Caswell

unread,
May 29, 1998, 3:00:00 AM5/29/98
to

On 29 May 1998, Jonadab wrote:

> Actually, I'm not against save & restore or undo, but I am against multiple
> undo. I think that goes a step too far in making the game too easy, and
> I'm going to attempt to disable it in my game, Diary of a Text Adventurer.
>

Just run the save_undo opcode 50 or 60 times before each command
prompt. That'll do a nice little number on anyone trying multi-undo. :)
It's a lot like what some annoying webpages do, with a sequence of 10 or
so auto-reload links, to prevent anyone from leaving their page with
"back".

---GEC


Jonadab

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

> > Actually, I'm not against save & restore or undo, but I am against
multiple
> > undo. I think that goes a step too far in making the game too easy,
and
> > I'm going to attempt to disable it in my game, Diary of a Text
Adventurer.
>
> First time I do something that puts the game in an unwinnable state and I
> can't multiple-undo out of it, I'll very probably quit the game and never
come
> back.

I was planning to make it difficult to get the game into an "unwinnable"
state -- though I don't care to make it *impossible*. The player can
always take some very necessary item and toss it in the washing machine
along with the marzipan cone and set the thing running and lose it forever,
but that kind of stupidity is the player's own fault. (Not that I never
try that sort of nonsense myself...)



> Inconveniencing the player for the sake of making the game hard is not my
idea
> of a good idea.

How many others feel this way? If it's a clear majority or even a large
minority I may retract my decision.

> If you want to make the game realistic, write a loader that deletes the
game
> file as soon as the player dies.

I didn't say I wanted to make the game insanely difficult. Realism wasn't
really the concern, either. I just thought multiple undo made it TOO easy.

Then again, how many multiple undos are we talking about? If the player
just uses up to five or six in a row, it's no big deal in a game of any
length. But if 50 or 100... How many can typically be stored on a
computer with plenty of RAM?



> Or better yet, write a loader that electrocutes the player as soon as the
> character dies.

That will have to wait for a more realistic game than mine.

--
From 501 uses for peanut butter:

424. "Back in my day we didn't HAVE so much peanut
butter. Peanut butter was for Sunday dinner ONLY."

My Current Quote: "Ah, this is obviously some new
definition of 'safe' of which I was not previously aware."

Jonadab

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

> > Actually, I'm not against save & restore or undo, but I am against
multiple
> > undo. I think that goes a step too far in making the game too easy,
and
> > I'm going to attempt to disable it in my game, Diary of a Text
Adventurer.
>
> Well, you can't in Inform; it's part of WinFrotz, not your game.
Although

You can in Inform. I did it last night.

Haven't made the final decision whether to keep it, though.

> you could probably do that in TADS.
>
> But disabling it would be a mistake, anyway. Multiple undos are a
> convenience to the player, and it should be a player choice, not an
author
> one.
>
> IMHO, of course.

That makes two I've seen against it.

>
> -Lucian

Mary K. Kuhner

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

In article <01bd8ba0$e6ad7ec0$0a118fd1@jonadab>,
Jonadab <jon...@bright.net> wrote:

>I was planning to make it difficult to get the game into an "unwinnable"
>state -- though I don't care to make it *impossible*. The player can
>always take some very necessary item and toss it in the washing machine
>along with the marzipan cone and set the thing running and lose it forever,
>but that kind of stupidity is the player's own fault. (Not that I never
>try that sort of nonsense myself...)

Watch out for strings of single-letter commands that lead to disaster:
some of us have cats who sit on the keyboard. :-)

>Lucian (I think) wrote:
>> Inconveniencing the player for the sake of making the game hard is
>>not my idea of a good idea.

>How many others feel this way? If it's a clear majority or even a large
>minority I may retract my decision.

Count me in. Players who dislike multiple undo (I don't use it,
actually) are free not to use it. Players who do like it--because
their cats are worse than mine, because save/restore is slow on
their machine or file space is tight, because it interrupts the
flow of the game less for them--will simply get angry if you
disallow it. In my opinion the difficulty of the game should flow
from its content, not from mechanical impediments.

It's just a less tedious save/restore, really, and why make things
tedious? Tedium is your enemy--it makes people stop playing your
game.

Mary Kuhner mkku...@genetics.washington.edu

Paul David Doherty

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

In article <01bd8ba1$de24ef80$0a118fd1@jonadab>,
Jonadab <jon...@bright.net> wrote:

[about disabling multiple UNDO]

>> Well, you can't in Inform; it's part of WinFrotz, not your game.
>

>You can in Inform. I did it last night.
>
>Haven't made the final decision whether to keep it, though.

Erm, you can't, actually. The multiple UNDO functionality built
into WinFrotz (or actually Frotz - WinFrotz is only a port) works
independently of whether your game supports UNDO or not.

-- Dave


Ola Sverre Bauge

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

Jonadab wrote...
>L. Ross Raszewski wrote...

>I was planning to make it difficult to get the game into an
>"unwinnable" state -- though I don't care to make it *impossible*.
>The player can always take some very necessary item and toss it
>in the washing machine along with the marzipan cone and set the
>thing running and lose it forever, but that kind of stupidity is the
>player's own fault. (Not that I never try that sort of nonsense
>myself...)

Well, what if I thought I needed a marzipan-flavored tiara to make the
raven I saw earlier ill, giving me free access to its nest? :-)

But seriously, punishing the players for experimenting with the
environment is *NOT* a good way to make them enjoy playing the game.
People will think of the craziest solutions to a puzzle, and if they're
punished for trying them, they will probably get stuck and give up
earlier if the exact thing that would have solved the puzzle is
something they didn't dare to try lest they get whacked over the head...
again.

Even with undo, I find that death is still a sting that removes most of
my incentive to play around with whatever it is that caused it, and
usually also lessens my desire to keep playing the game ~ so if this
hypothetical game required me to solve a puzzle by way of something
involving the washing machine, I'd probably miss it if I was punished
for experimenting with it earlier, and I'd probably stop playing the
game sooner whether I had solved or not.

Still, some blatantly hazardous actions would have to warrant death to
keep the game from just posing empty threats, but as has been pointed
out earlier by Den and Whiz, the technique often used is to have the
player-character refuse to carry out the hazardous action, in the
interest of his/her own safety and wellbeing.

>> Inconveniencing the player for the sake of making the game hard is
>>not my idea of a good idea.
>
>How many others feel this way?

<raises hand> If you need to disable undo to make your game hard, then
it's not undo that's your problem, it's the puzzle / game design that's
at fault.

>Then again, how many multiple undos are we talking about? If the
>player just uses up to five or six in a row, it's no big deal in a game
>of any length. But if 50 or 100... How many can typically be stored
>on a computer with plenty of RAM?

Just checked with Anchorhead on WinFrotz, and I was allowed 26 undos (if
I counted correctly, that is), and that's on a computer with 48 MB of
RAM.

>> Or better yet, write a loader that electrocutes the player as soon as
>>the character dies.
>
>That will have to wait for a more realistic game than mine.

raif, dateline 2036 AD: [announce] 'A New Day' release 57 - now in
glorious Zap-O-Rama! (Requires Creative PlayerBlaster OWW64)

Jonadab

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

> Jonadab <jon...@bright.net> wrote:
>
> [about disabling multiple UNDO]
>
> >> Well, you can't in Inform; it's part of WinFrotz, not your game.
> >
> >You can in Inform. I did it last night.
> >
> >Haven't made the final decision whether to keep it, though.
>
> Erm, you can't, actually. The multiple UNDO functionality built
> into WinFrotz (or actually Frotz - WinFrotz is only a port) works
> independently of whether your game supports UNDO or not.

I'm aware of that. The game DOES support single undo, and furthermore the
multiple undo hotkey works as single-undo, but if you try it again you get
a redo.

However, I didn't say that it could be done *straightforwardly*.

I'll adjust one of the Inform examples and send you a binary for
demonstration, if you like.



--
From 501 uses for peanut butter:

417. If you cannot get to the laundromat and you run
out of clean laundry, wear peanut butter under
your clothing to cover the smell.

Jonadab

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

> Jonadab <jon...@bright.net> wrote:
>
> >I was planning to make it difficult to get the game into an "unwinnable"
> >state -- though I don't care to make it *impossible*. The player can
> >always take some very necessary item and toss it in the washing machine
> >along with the marzipan cone and set the thing running and lose it
forever,
> >but that kind of stupidity is the player's own fault. (Not that I never
> >try that sort of nonsense myself...)
>
> Watch out for strings of single-letter commands that lead to disaster:
> some of us have cats who sit on the keyboard. :-)

I think about the only bad thing that can happen with single letter
commands would be if you accidentally walked off the roof and died -- but
that can be repaired with single undo.



> >Lucian (I think) wrote:
> >> Inconveniencing the player for the sake of making the game hard is
> >>not my idea of a good idea.

Come to think of it, if I wanted to inconvenience the player I would have
set player.capacity to 4 instead of coding up an autosave feature.

If I wanted to make the game hard I wouldn't be coding up a hint feature.

I just sort of felt that multiple undo is like cheating. Then again, some
people have told me that saving and restoring is like cheating, and I
wholeheartedly disagree there...



> >How many others feel this way? If it's a clear majority or even a large
> >minority I may retract my decision.
>
> Count me in. Players who dislike multiple undo (I don't use it,

> actually) are free not to use it...

Three to nothing against so far -- it looks like I'll have to repent.

> In my opinion the difficulty of the game should flow
> from its content, not from mechanical impediments.

Of course. There is one instance, though, where I require a mildly tedious
activity for the sake of it, but I think in that case it produces a greater
sense of accomplishment when the result opens up a whole new area of the
game. Also, I expect the majority of players to save at that point.



> It's just a less tedious save/restore, really, and why make things
> tedious? Tedium is your enemy--it makes people stop playing your
> game.

Well, my thinking was that save/restore forces the player to choose when to
save, whereas multiple undo keeps it waiting. Even my autosave feature
requires the player to choose whether to save every time the score goes up
or every N turns (and to specify N), so there's still the requirement to
make the decision. I'll have to think about this some more.

There's also the issue that multiple-undo is outside the z-machine's specs,
so in a sense it is cheating -- and there's no way to control or limit it.
What I'd really like to do is limit it to, say, 20 consecutive undos; I
can't do that, because I have no way to determine when the player is using
the multiple undo feature, since its behavior is totally outside of the
game's code, including the library.

On the other hand, the method I would use to prevent it could also be
considered cheating, in another sense, again because it relies on doing
something not expected. (In this case, the game is doing something Frotz
doesn't expect, instead of the other way around.)

> Mary Kuhner mkku...@genetics.washington.edu
>

--
From 501 uses for peanut butter:

424. "Back in my day we didn't HAVE so much peanut
butter. Peanut butter was for Sunday dinner ONLY."

Jonadab

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

> Jonadab wrote...
> >L. Ross Raszewski wrote...
>
> But seriously, punishing the players for experimenting with the
> environment is *NOT* a good way to make them enjoy playing the game.
> People will think of the craziest solutions to a puzzle, and if they're
> punished for trying them, they will probably get stuck and give up
> earlier if the exact thing that would have solved the puzzle is
> something they didn't dare to try lest they get whacked over the head...
> again.

Actually, I was trying to go out of my way to make experimenting result in
interesting stuff. The cone is nowhere near the washer, and neither is
essential to winning the game (though points can be scored related to one
of them).

As I said in another post, too, death can be fixed with single undo unless
there's a slow poison involved or somesuch.



> Even with undo, I find that death is still a sting that removes most of
> my incentive to play around with whatever it is that caused it, and
> usually also lessens my desire to keep playing the game ~ so if this
> hypothetical game required me to solve a puzzle by way of something
> involving the washing machine, I'd probably miss it if I was punished
> for experimenting with it earlier, and I'd probably stop playing the
> game sooner whether I had solved or not.

Hmmm...


> Still, some blatantly hazardous actions would have to warrant death to
> keep the game from just posing empty threats, but as has been pointed
> out earlier by Den and Whiz, the technique often used is to have the
> player-character refuse to carry out the hazardous action, in the
> interest of his/her own safety and wellbeing.

I disagree with that on the principle that I want the player to almost
become the character -- particularly in this particular game... I'd better
not say any more about that just yet.



> >> Inconveniencing the player for the sake of making the game hard is
> >>not my idea of a good idea.
> >

> >How many others feel this way?
>

> <raises hand> If you need to disable undo to make your game hard, then
> it's not undo that's your problem, it's the puzzle / game design that's
> at fault.

As I said, making the game hard wasn't the point, but never mind.
This makes four to zero against disabling multiple undo, which means I'll
undoubtedly end up leaving it enabled on the principle that I want my game
to be played.



> >Then again, how many multiple undos are we talking about? If the
> >player just uses up to five or six in a row, it's no big deal in a game
> >of any length. But if 50 or 100... How many can typically be stored
> >on a computer with plenty of RAM?
>
> Just checked with Anchorhead on WinFrotz, and I was allowed 26 undos (if
> I counted correctly, that is), and that's on a computer with 48 MB of
> RAM.

(sheepishly) Well, what was I worried about? Never mind the whole thing.

> >> Or better yet, write a loader that electrocutes the player as soon as
> >>the character dies.
> >
> >That will have to wait for a more realistic game than mine.
>
> raif, dateline 2036 AD: [announce] 'A New Day' release 57 - now in
> glorious Zap-O-Rama! (Requires Creative PlayerBlaster OWW64)

Actually, I am among the half-crazed fringe that would actually consider
playing a game capable of causing the player pain in proportion to the pain
of the character -- up to a point well short of death or injury, of course.

Now you know I'm a lunatic. Ah, well. It was bound to come out sooner or
later.

--
From 501 uses for peanut butter:

417. If you cannot get to the laundromat and you run
out of clean laundry, wear peanut butter under
your clothing to cover the smell.

Lelah Conrad

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

On 30 May 1998 14:07:37 GMT,


>>How many others feel this way? If it's a clear majority or even a large
>>minority I may retract my decision.
>

>Count me in. ...


>It's just a less tedious save/restore, really, and why make things
>tedious? Tedium is your enemy--it makes people stop playing your
>game.

100% agreement here. If you make it hard for me I will _not_ continue
playing your game. There is just too much IF now to stick with
something that is completely frustrating, hence tedious. I think
games should provide complete hints, walkthroughs, multiple undo, etc.
-- whatever it takes to allow players to get on with it. I look at IF
like I do books and videos-- sometimes I skip around in them, or just
read endings, or fastforward, or cut to the good parts, etc. I know
there are people with objections to this, but for me, life is just too
short, and there are way too many IF games to play, books to read,
great videos to watch, etc. to sit and bang my head against a computer
screen. (This doesn't mean I'm not going to try your puzzles -- I
am. It just means that if they frustrate me unduly, I'm outa there,
expecially if you haven't provided me with hints or a walkthrough.)

Lelah

Branko Collin

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

On Thu, 28 May 1998 11:55:38 +0100, Iain Merrick <i...@cs.york.ac.uk>
wrote:

>Ben wrote:
>
>> In article <6kh6rd$sga$1...@joe.rice.edu>, lps...@rice.edu (Lucian Paul
>> Smith) wrote:
>>

>> > The more I think about it, the more I believe our strongest objections to
>> > this kind of thing stem from our preconceptions about books--certainly,
>> > the protagonist of a book does not have the luxury of failing to stop the
>> > train before it crashes, learning from it, and going back to save the same
>> > train a second time.
>>
>> Books? Try life! Its not "realistic" to be able to undo. In REAL LIFE you
>> don't go into a situation knowing what is going to happen, or doing
>> something foolish because you know you can undo. I'll say the word... It
>> breaks mimesis.
>>
>> Not that I am against undo, mind you. :) The point of good IF, IMO, is to
>> have fun. Trinity with no save/restore/undo would NOT be fun AT ALL.
>

>Hmmm...
>
>------
>
>> SQUEEZE POD
>
>As you crush the seed pod, a pungent oily substance drips between your
>fingers. You suddenly realise that this is just what you need to solve
>the Deeply Symbolic puzzle you passed earlier, but that by crushing the
>pod here you've gone and mucked things up.
>
>> UNDO
>
>That's not how life works.
>
>> DAMN AND BLAST
>
>Real adventurers do not use such language.
>
>> RESTORE
>
>That's not how life works.
>
>> QUIT
>
>That's not how life works.
>
>> [CTRL-ALT-DEL]
>
>That's not how life works.
>
>> [Reaches for power switch; pauses, warily...]

I see you have been playing BLAZEMONGER. I hope you haven't actually
tried to pull the plug. Their customer support service ... how do I
put this gently ... might be slightly worried about that?

--
branko collin, col...@xs4all.nl
i have been in you
you have been in me - f. zappa

Adam J. Thornton

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

In article <01bd8c00$a64880e0$10118fd1@jonadab>,

Jonadab <jon...@bright.net> wrote:
>Actually, I am among the half-crazed fringe that would actually consider
>playing a game capable of causing the player pain in proportion to the pain
>of the character -- up to a point well short of death or injury, of course.
>Now you know I'm a lunatic. Ah, well. It was bound to come out sooner or
>later.

I see you've been playing "Detective" and "My First Stupid Game," then.

Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman

Darin Johnson

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

lps...@rice.edu (Lucian Paul Smith) writes:

> But disabling it would be a mistake, anyway. Multiple undos are a
> convenience to the player, and it should be a player choice, not an author
> one.

If someone wants to disable it, then they should also design the game
so it's not as necessary as single undos. Ie, I find multiple undos
very useful when it takes multiple moves of a mistake until you find
out you made the mistake. For instance, let's say you drop the Magic
Squeegee of Horlicks, and by doing so, you'll be killed when you leave
the room; but if you look around the room, you've wasted multiple
moves, and a single undo won't be able to fix things for you.

Multiple undos are also good for the omnipresent yet despised mazes.

--
Darin Johnson
da...@usa.net.delete_me

Paul A Krueger

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

Paul David Doherty wrote in message <6kpdks$3...@joker.rz.hu-berlin.de>...

>Erm, you can't, actually. The multiple UNDO functionality built
>into WinFrotz (or actually Frotz - WinFrotz is only a port) works
>independently of whether your game supports UNDO or not.


Actually, you *can* disable it for certain puzzles (don't ask me how,
though). I just checked the 3-door puzzle in Zork 0 using WinFrotz and both
save and undo *were* disabled (didn't check restore).

I agree with the majority though, that I'd be highly suspicious of the
fairness of a puzzle that did this.

Paul A Krueger

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

Jonadab wrote in message <01bd8c28$a0b77500$LocalHost@jonadab>...
>Then I certainly must allow multiple undos, because I reluctantly decided
>that a game called "Diary of a Text Adventurer", embodying the experiences
>of a text adventurer, just had to have one little maze in it somewhere. I
>tried to think of a way out -- really -- because I hate the things too. At
>least I limited it to about 6 rooms and made all but two of them easily
>distinguishible... does that mitigate the maze's very presence?


I usually save UNDOing for life and death situations, so unless I could die
from getting stuck (IE. Run out of food/drink or light) I wouldn't undo in a
maze.

Also, there are ways to *know* were to go in a maze:

Cleverly disguised maps (Monkey Island and Leisure Suit Larry 3)
Following someone who knows were to go (Monkey Island)
Bat Guano (Return to Zork)
Magical items (Monkey Island)
Subtlely changing the description (Original Adventure)
and lastly, could it be, yes it's...Draw a map!!

Weird Beard
weird...@prodigy.net

For a long moment, Ur-Grue looked on incredulously. «What in the name of the
Implementors are you?»
«Well, I should think it would be patently obvious that we're grues, now,
wouldn't it?», a 'grue' who looked a lot like John Cleese replied.
«You are not grues,» Ur-Grue growled.
«Oh, sure we are,» one who looked like Michael Palin countered. «The
Antharian Blue species. Lovely spines, don't you think?»
«The spines fail to come into it! You are humans in cheap foam rubber
suits!»
The Palin grue hesitated. «We've... been sick.»

Unlikely Aliens #8, Scott Johnson

Joe Mason

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

Paul Francis Gilbert wrote:
>
> Anyone else remember the great debate over 'take all' we had a while back?

I remember A debate. Was it a GREAT debate?

Joe

Paul A Krueger

unread,
May 30, 1998, 3:00:00 AM5/30/98
to

Paul A Krueger wrote in message
<6kq4m9$6obe$1...@newssvr04-int.news.prodigy.com>...

Aarrgghh!! I was looking at my *score*! However undo will still not help,
because the answer is randomized (I accidently picked the right door, undid
and chose the wrong one)

This type of puzzle is still pretty annoying though.

Jonadab

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

> If someone wants to disable it, then they should also design the game
> so it's not as necessary as single undos. Ie, I find multiple undos
> very useful when it takes multiple moves of a mistake until you find
> out you made the mistake. For instance, let's say you drop the Magic
> Squeegee of Horlicks, and by doing so, you'll be killed when you leave
> the room; but if you look around the room, you've wasted multiple
> moves, and a single undo won't be able to fix things for you.

If the game allows you to pick the squeegee up again, then it will.



> Multiple undos are also good for the omnipresent yet despised mazes.

Then I certainly must allow multiple undos, because I reluctantly decided


that a game called "Diary of a Text Adventurer", embodying the experiences
of a text adventurer, just had to have one little maze in it somewhere. I
tried to think of a way out -- really -- because I hate the things too. At
least I limited it to about 6 rooms and made all but two of them easily
distinguishible... does that mitigate the maze's very presence?

--

Stephen Robert Norris

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

In article <6kq4m9$6obe$1...@newssvr04-int.news.prodigy.com>,
"Paul A Krueger" <WEIRD...@prodigy.net> intoned:

>
> Paul David Doherty wrote in message <6kpdks$3...@joker.rz.hu-berlin.de>...
>
>>Erm, you can't, actually. The multiple UNDO functionality built
>>into WinFrotz (or actually Frotz - WinFrotz is only a port) works
>>independently of whether your game supports UNDO or not.
>
>
> Actually, you *can* disable it for certain puzzles (don't ask me how,
> though). I just checked the 3-door puzzle in Zork 0 using WinFrotz and both
> save and undo *were* disabled (didn't check restore).

I wonder how - I thought that Frotz's undo (alt-u on my version) was
outside the virtual machine - it reverted the virtual machine state.

Have I misunderstood?

Stephen

Paul Francis Gilbert

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

A thing I think a lot of people are missing here is...

Text adventures, are by definition, games. They're meant to be fun to play,
not so realistic that people give up in disgust. How many people would play
a flight simulator game which required you to have a pilot's license just to
figure out how to work the controls?

Likewise, in IF games we make concessions to the realism to enable the
game to play efficiently and the user to be able to use it with a minimum of
fuss. The traditional libraries, for example, take numerous shortcuts when
evaluating things like visibility... which is why the WorldClass library was
created to try and address some of them, and consequently required a
386/486 to run on.

So, I don't think multiple undos / foreknowledge really hurts a game.
Because in the end, that's what it is. A game. Which is meant to be played.


--
Paul Gilbert | p...@yallara.cs.rmit.edu.au (The DreamMaster)
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 5, RMIT Melbourne | as such will contain no references to small furry
Australia | creatures from Alpha Centauri.

Paul Francis Gilbert

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

"Jonadab" <jon...@bright.net> writes:

>That makes two I've seen against it.

>--

>From 501 uses for peanut butter:

>424. "Back in my day we didn't HAVE so much peanut
>butter. Peanut butter was for Sunday dinner ONLY."
>

> My Current Quote: "Ah, this is obviously some new
> definition of 'safe' of which I was not previously aware."

> "I" /\ \I /\ I\ /\ I) /\ I) I) 1 /_ II "I" \I [" "I"
> \I \/ I\ II I/ II I) \a I) I\ 1 \/ TT I o I\ [_ I

Make that three. I agree... multiple undo should be a player decision, not
an authors (especially considering you can do the same with save/undo, so
allowing multiple undo isn't really amything more than a framewark over that
preexisting functionality).

Anyone else remember the great debate over 'take all' we had a while back?

;-)

Paul Francis Gilbert

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

"Paul A Krueger" <WEIRD...@prodigy.net> writes:


>Paul David Doherty wrote in message <6kpdks$3...@joker.rz.hu-berlin.de>...

>>Erm, you can't, actually. The multiple UNDO functionality built
>>into WinFrotz (or actually Frotz - WinFrotz is only a port) works
>>independently of whether your game supports UNDO or not.


>Actually, you *can* disable it for certain puzzles (don't ask me how,
>though). I just checked the 3-door puzzle in Zork 0 using WinFrotz and both
>save and undo *were* disabled (didn't check restore).

>I agree with the majority though, that I'd be highly suspicious of the


>fairness of a puzzle that did this.

I think there's confusion here with some people about WinFrotz's undo
behavoir. In addition to the standard save_undo opcode in the Z-machine
(which is iffy whether it supports multiple undo at all), WinFrotz also
saves the z-machine state after each turn into a buffer.

Using a hotkey, Alt-U I think it was, causes WinFrotz to reload the previous
game-state, which effectively "undoes" a previous turn. I'm not sure of the
exact mechanics, but I think it uses a fixed size buffer which can accomodate
several turns worth of undo images before discarding the oldest.

There is thus no way to disable WinFrotz's "hotkey" undo without extending
the z-machine to include state bits and allocating one to tell WinFrotz not
to support multiple undo, and as we all know, suggesting the extension of
the z-machine is a cardinal sin. ;-)

Jonadab

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

George Caswell <timb...@wpi.edu> wrote:
> On 29 May 1998, Jonadab wrote:
>
> Just run the save_undo opcode 50 or 60 times before each command

Actually, twice is all that's necessary. I don't know why, but running it
twice in succession causes a second multi-undo to undo the first undo --
that is, it turns multi-undo into redo. I don't know enough about the
inner workings of Frotz to know why this is so, but it is. So all you have
to do to disable multi-undo is find the place in Keyboard (in parser.h for
Inform 5) where it saves the undo information and double-up the line. I
figured somebody else would think of that.

> prompt. That'll do a nice little number on anyone trying multi-undo. :)
> It's a lot like what some annoying webpages do, with a sequence of 10 or
> so auto-reload links, to prevent anyone from leaving their page with
> "back".

No, that's just evil. However, a good browser considers a reload of the
same link to be the same for history purposes, so it won't work. I am
told, however, that there's a way to prevent the user from leaving the page
via JavaScript. I'm planning to attempt to implement this if possible as
part of my "Worst Page on the Internet" example. Along with at least a
dozen unresizeable frames and 20-30 gratuitous animations, of course ;-)


--
From 501 uses for peanut butter:

417. If you cannot get to the laundromat and you run
out of clean laundry, wear peanut butter under
your clothing to cover the smell.

George Caswell

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

On 30 May 1998, Jonadab wrote:

> I just sort of felt that multiple undo is like cheating. Then again, some
> people have told me that saving and restoring is like cheating, and I
> wholeheartedly disagree there...
>

The distinction is purely one of convenience. The only difference
between allowing the player use of a save file and allowing multiple undo
is how much work it takes the player to do what they want. (The exception
being if the game only allows saves at certain locations, and the
interpreter doesn't support saves that aren't performed by the game) A
player can 'undo' in a game and interpreter that don't support it by
saving each turn and restoring when they need to. All you accomplish by
not allowing players to undo directly is waste their time and piss them
off.

> There's also the issue that multiple-undo is outside the z-machine's specs,

<shrug> If it becomes apparent that the current implementations of
multiple-undo are actually incompatible with the Z-spec (I don't believe
they are) it can become an interpreter feature.

> so in a sense it is cheating -- and there's no way to control or limit it.

Players have always been able to cheat. They can view the encoded
Z-strings, they can scan the object tables and dictionary, they can
disassemble the damn thing if they want.
And like I said before, if saving isn't cheating, then neither is undo.
Undo is just implicit, more convenient. It's the player's decision
whether this breaks some precious mimesis rule or if their conscience can
take it.

---GEC


Jonadab

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

Paul Francis Gilbert <p...@cs.rmit.edu.au> wrote in article
<6kqceu$qif$1...@goanna.cs.rmit.edu.au>...


>
> Make that three. I agree... multiple undo should be a player decision,
not
> an authors (especially considering you can do the same with save/undo, so
> allowing multiple undo isn't really amything more than a framewark over
that
> preexisting functionality).

It's a lot more than three now, with no one defending my original position,
so I've agreed to allow multiple undo even if I don't care for it.

I've also discovered as an added consequence how to generate extra posts.
Next time I'm feeling ignored, I'll just threaten to disable all the
abbreviations or something...

> Anyone else remember the great debate over 'take all' we had a while
back?
> ;-)

Actually, I allow "x all" in my game. Would that almost make up for
disabling multiple-undo?

Jonadab

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

Paul A Krueger <WEIRD...@prodigy.net> wrote in article
<6kqji3$978s$1...@newssvr04-int.news.prodigy.com>...

Yes, I don't care for random solutions. I like randomness for atmosphere,
but I don't care for forcing the player to take a 60% chance of death in
order to win, or whatever. If I were ever to implement that I'd need a
terribly good reason, and I can't think of one at the moment.

George Caswell

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

On 30 May 1998, Jonadab wrote:

> Then again, how many multiple undos are we talking about? If the player
> just uses up to five or six in a row, it's no big deal in a game of any
> length. But if 50 or 100... How many can typically be stored on a
> computer with plenty of RAM?
>

For a Z-machine, probably 100K or so, tops. Potentially much less if
you compress them (differential-RLE, for example). Just about all 386es
and better will probably have enough RAM for at least 30 (3 MB / 100 KB, 1
MB reserved for OS and interpreter.) Any OS equipped to take advantage of
the 386's memory management can also swap pages to disk, so virtual memory
is a factor as well.
Of course, interpreter implementors could be clever about this-- if
the right data structure is constructed, UNDO snapshots can be represented
as differentials relative to -each other-. Since each one is usually just
one move apart from the ones before and after it, a very long string of
sequential UNDO snapshots could probably be stored in about the same
amount of storage as one or two uncompressed snapshots.

> > Or better yet, write a loader that electrocutes the player as soon as the
> > character dies.
>
> That will have to wait for a more realistic game than mine.
>

I'm going to do the next best thing. If the player has the Rumble
Pak(tm) accessory, it will vibrate any time they die. Now -that's-
reality!

---GEC


Jonadab

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

Paul Francis Gilbert <p...@cs.rmit.edu.au> wrote in article

<6kqd56$qt9$1...@goanna.cs.rmit.edu.au>...


> "Paul A Krueger" <WEIRD...@prodigy.net> writes:
>
> >Actually, you *can* disable it for certain puzzles (don't ask me how,
> >though). I just checked the 3-door puzzle in Zork 0 using WinFrotz and
both
> >save and undo *were* disabled (didn't check restore).
>
> >I agree with the majority though, that I'd be highly suspicious of the
> >fairness of a puzzle that did this.
>
> I think there's confusion here with some people about WinFrotz's undo
> behavoir. In addition to the standard save_undo opcode in the Z-machine
> (which is iffy whether it supports multiple undo at all), WinFrotz also
> saves the z-machine state after each turn into a buffer.

I'm not sure precisely how it works, but I think that what it does is save
each successive piece of undo information in a separate slot. You can
specify the number of slots on the command line for the DOS version.



> Using a hotkey, Alt-U I think it was, causes WinFrotz to reload the
previous
> game-state, which effectively "undoes" a previous turn. I'm not sure of
the
> exact mechanics, but I think it uses a fixed size buffer which can
accomodate
> several turns worth of undo images before discarding the oldest.

Right. Only it's not totally fixed, since you can specify how many undos
to allow -- but it only goes up to as many as RAM allows, of course.



> There is thus no way to disable WinFrotz's "hotkey" undo without
extending
> the z-machine to include state bits and allocating one to tell WinFrotz
not
> to support multiple undo, and as we all know, suggesting the extension of
> the z-machine is a cardinal sin. ;-)

Actually, if the z-machine supported multi-undo, we could set a limit --
say, allow up to 20 successive undos and no more. But we can't do that,
because we can't determine how many successive undos have been used. What
we CAN do, however, is trick Frotz. If at any point we decide we don't
want the player multi-undoing back prior to a certain point, we just call
the save_undo opcode twice in succession at that point, and it turns the
last undo into a redo -- I'm not sure exactly how or why, and now that I've
pointed it out it will probably get "fixed" in the next version, but that's
life, I guess.



--
From 501 uses for peanut butter:

83. Spread it on your left hand. Let it dry. Rub
your hands together until you have little clumps
and rolls of dried peanut butter. Spread them
around on your test paper to make it look like
you erased a lot.

My Current Quote: "Whoooo hoo hoooo!"

Matt Kimball

unread,
May 31, 1998, 3:00:00 AM5/31/98