A Bill of Author's Rights
b_fe...@yahoo.com
[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
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
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
Dan Shiovitz
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
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
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
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
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
>
> 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
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
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
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
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
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
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
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
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
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
And as a jelly major, I'd like to know too!!!
Joe
Giles Boutel
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
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
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
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
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
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
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
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!!!
>
> 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.
>
> 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.
>
>
> 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
> > 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
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
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
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
> > 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.
>
> 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
> > 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.
>
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
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
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
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
> 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
> 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...)
>
> 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
> Jonadab wrote...
> >L. Ross Raszewski wrote...
>
> 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
On 30 May 1998 14:07:37 GMT,
mkku...@evolution.genetics.washington.edu (Mary K. Kuhner) wrote:
>>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
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
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
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
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
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
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
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
> 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
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
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
"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
"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
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
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
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
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
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
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
Jonadab <jon...@bright.net> 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...
: 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.)
Psst. If the player wants to cheat, I say we let him cheat. It's not
like its unfair to the rest of us if he does. He is the one playing
the game after all, so maybe he should be the one to make the decision
to use multiple undo or save/restore to solve puzzles.
--
Matt Kimball
mkim...@xmission.com
Gunther Schmidl
Jonadab wrote:
>Actually, I allow "x all" in my game. Would that almost make up for
>disabling multiple-undo?
NO!
I want multiple undo!
:)
--
+------------------------+----------------------------------------------+
| Gunther Schmidl | "I couldn't help it. I can resist everything |
| Ferd.-Markl-Str. 39/16 | except temptation" -- Oscar Wilde |
| A-4040 LINZ +----------------------------------------------+
| Tel: 0732 25 28 57 | http://gschmidl.home.ml.org - new & improved |
+------------------------+---+------------------------------------------+
| sothoth (at) usa (dot) net | please remove the "xxx." before replying |
+----------------------------+------------------------------------------+
Jason Westman
Jonadab wrote:
>
> George Caswell <timb...@wpi.edu> wrote:
> > 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 ;-)
Also the IE4/NS4 browsers have multiple "back"...
But that's cheating, so nobody uses it ;)
=> Jason!
--
"Cougars can leap 20 thousand feet... When pushed out of an airplane."
--Changa
Spamblocked, remove passion to reply!
Benjamin Kenward
on the subject of disabling undo... my work in progress has a puzzle in which
the player must influence a sequence of random events (ok, so they have to
cheat at dice). i realised that it would be possible to cheat in _entirely_ the
wrong way by using undo, so i disabled it (only for that puzzle). (im using
inform, so it was easy). but now i read that winfrotz undo is seperate from
the z-machine undo... so is there really nothing i can do to prevent people
cheating here?
ben
Andrew Plotkin
Someone posted a method which seems to prevent, or at least, screw up,
frotz's multiple-undo.
It involved doing the @save_undo opcode twice. Of course, this is a slow
function on any interpreter. So you're inconveniencing all your players
to stop cheaters.
And, who knows, maybe the next version of frotz will be able to work
around this method. After all, it's entirely outside the spec; there's
nothing to say what it can or can't do. Then players would just have to
hit the undo hotkey 2*N times to undo N moves.
I think this is just like the copy-protection mess; it's not worth
getting into. (Even less so than copy protection, in fact. Pirating
hurts authors; cheating only affects players who choose to do it.)
You can go back and forth for years, figuring out workarounds to the
"other side"s workarounds, and the only people that really get hurt are
the ordinary players. It will cause some slowdowns; it may cause
compatibility problems someday. That's just a feeling, but I trust my
feelings.
Anyway, nothing you can do will prevent people from disassembling your
z-code file, which is far deeper cheating than multiple undo on a dice
puizzle.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
L. Ross Raszewski
In article <6kqc31$45o$1...@crux.cs.usyd.edu.au>,
s...@fn.com.au wrote:
>
>
> 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?
Well, sorta. I don't really understand how frotz does it, but here's what I;m
guessing
THe spec doesn't specifically say that multiple undo is not allowed, but hte
undo action in inform checks withere the game was just undone, which is why
multiple undo is not available.
When frotz calls @save_undo, information already in the undo buffer is pushed
back a space, rather than discarded. multiple undo is _not_ illegal in the
spec (unless my copy is missing a page), it's simply _blocked_ by inform (for
the reason that most terps don't support it)
Frotz's <alt-u> command presumably executes the @restore_undo opcode, without
running through inform's error-checking.
Therefore, by executing @save_undo a whole bunch of times within the game,
frotz will fill its internal buffer of undoes all at once.
AFAIK, frotz does not store undoes spearately from the Z-machine, as it has no
way of knowing when one turn is up (it can't simply do it when a key read is
called, otherwise alt-u would undo up to, but not over, a <press any key to
continue>
Instead, frotz reads into its undo buffer whenever @save_undo is called.
Presumably, if you took all instances of @save_undo out of the library, undo
would not work at all (maybe)
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Darin Johnson
Personally, I just don't see a valid *reason* to disallow multiple undo's.
--
Darin Johnson
da...@usa.net.delete_me
Darin Johnson
"Paul A Krueger" <WEIRD...@prodigy.net> writes:
> I agree with the majority though, that I'd be highly suspicious of the
> fairness of a puzzle that did this.
Some puzzles based upon a random sequence can be solved with undo's.
Ie, let's say you're supposed to find a map to get you through a mine
field. The mines are placed randomly. A player without the map could
undo everytime the character died, and move a different direction.
The puzzle itself is fair, but restore/undo could bypass it.
One solution is to disallow undo/save while on the minefield. Another
that TADS allows, is to set a function hook called after restore or
undo that will regenerate the minefield and move player to the start
of it.
--
Darin Johnson
da...@usa.net.delete_me
George Caswell
On Sun, 31 May 1998, Andrew Plotkin wrote:
> Benjamin Kenward (some...@sable.ox.ac.uk) wrote:
> > on the subject of disabling undo... my work in progress has a puzzle in which
> > the player must influence a sequence of random events (ok, so they have to
> > cheat at dice). i realised that it would be possible to cheat in _entirely_ the
> > wrong way by using undo, so i disabled it (only for that puzzle). (im using
> > inform, so it was easy). but now i read that winfrotz undo is seperate from
> > the z-machine undo... so is there really nothing i can do to prevent people
> > cheating here?
>
> Someone posted a method which seems to prevent, or at least, screw up,
> frotz's multiple-undo.
>
But is that frotz's implementation of normal undo, or frotz's built-in
hotkey undo? The built in one decides when to save snapshots on its
own...
> And, who knows, maybe the next version of frotz will be able to work
> around this method. After all, it's entirely outside the spec; there's
> nothing to say what it can or can't do. Then players would just have to
> hit the undo hotkey 2*N times to undo N moves.
>
Actually, I think for n consecutive executions of save_undo, you'd have
to undo 2^n times to undo to the move before the sequence- The first time
you run that section of code, it saves n undo snapshots. When you undo,
the first one disappears. Undo again, and the second one disappears but
another comes back... (you restored the n-1th snapshot but regenerated
the nth one.) The next undo would re-undo the nth save_undo, the next the
n-2th (regenerating n-1 and n), etc...
---GEC
George Caswell
On Sun, 31 May 1998, Darin Johnson wrote:
> "Paul A Krueger" <WEIRD...@prodigy.net> writes:
>
> > I agree with the majority though, that I'd be highly suspicious of the
> > fairness of a puzzle that did this.
>
> Some puzzles based upon a random sequence can be solved with undo's.
> Ie, let's say you're supposed to find a map to get you through a mine
> field. The mines are placed randomly. A player without the map could
> undo everytime the character died, and move a different direction.
>
It would be just as well to not let the player even -enter- the mine
field without the map, since doing so would be patently stupid. That's a
better solution that trying to block save/restore/undo, particularly since
there's no way you can ever keep the interpreter from letting the user
bypass that sort of annoyance. (An interpreter can save and restore the
game state any time, whether it executes the save or restore opcodes or
not... It's sort of analogous to how some NES emulators can save the
entire system status to add game state saving to games that don't support
it.)
> The puzzle itself is fair, but restore/undo could bypass it.
>
Your version of the puzzle demands that the only proper solution is to
find the map to the mine field without entering it first. Disallowing
entry to the minefield is, I'll concede, not a great solution, but
certainly a reasonable one if you want to prevent people from mapping it
with UNDO.
Another reasonable solution would be to kill the player when they're in
the minefield whether they're on the right path or not, if they haven't
got the map- This is reasonable, since the character doesn't know where
the mines are and could easily stumble into one.
> One solution is to disallow undo/save while on the minefield. Another
> that TADS allows, is to set a function hook called after restore or
> undo that will regenerate the minefield and move player to the start
> of it.
>
Neither is really possible in the Z-machine unless the interpreter
cooperates- not if the interpreter allows the user to request a
save/restore/undo/redo independant of the game. (This is a reasonable
feature for interpreters to implement, particularly in GUI ones...) I
expect TADS would be similar, if an interpreter is made to allow the user
greater control over the virtual machine than the game demands...
I believe the Z-machine can be made to do the function hook, at least
if the player restricts themselves to the standard SAVE and RESTORE
commands. That could get strange, though, if the player drops or picks up
anything in the minefield...
---GEC
Michael Straight
On 30 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.
> >
> > 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.
I think that's silly. Multiple-undo is functionally identical to saving
one's game every move with a new name, except vastly easier (although it
wouldn't be *that* hard to make a macro to do it for you). Unless you
also plan to disable save and restore, all you're doing is making your
game more tedious for those who want to be able to multiple-undo, not
disallowing it completely.
SMTIRCAHIAGEHLT
Michael Straight
On Sun, 31 May 1998, Gunther Schmidl wrote:
> Jonadab wrote:
> >Actually, I allow "x all" in my game. Would that almost make up for
> >disabling multiple-undo?
>
> NO!
> I want multiple undo!
I demand "undo all"!
SMTIRCAHIAGEHLT
Joe Mason
Michael Straight wrote:
>
> > NO!
> > I want multiple undo!
>
> I demand "undo all"!
Well, in WinFrotz (and, I assume, Frotz) you can make it an alias for
"restart".
Joe
David Glasser
Jonadab <jon...@bright.net> wrote:
(I'm too lazy to put the quotes back, but the following is Jonadab,
Lucian Smith, and Jonadab.)
> > > 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.
What Lucian is saying is that even if you disable the undo command,
WinFrotz (and maybe other Frotzes) let you undo anyway. You can even do
it in Infocom games that don't support undo.
Though Inform doesn't support multiple undo in the first place.
--David Glasser
gla...@NOSPAMuscom.com | dgla...@NOSPAMfcs.pvt.k12.pa.us
http://onramp.uscom.com/~glasser | http://www.geocities.com/SoHo/6028
DGlasser @ ifMUD : fovea.retina.net:4000 (webpage fovea.retina.net:4001)
Interactive Fiction! MST3K! David Eddings! Macintosh!
Paul A Krueger
There are (including this post) currently 73 posts about UNDO, which
everyone seems to want and only 37 post about conversation, which nobody can
agree upon. What does *that* tell you?
L. Ross Raszewski
In article <Pine.OSF.3.96.980531...@wpi.WPI.EDU>,
Actually, I _beleive_ you can hook an undo as well, as the Z-machine sets a
flag to indicatethat an undo has just occured.
Gunther Schmidl
>> > on the subject of disabling undo... my work in progress has a puzzle in
which
>> > the player must influence a sequence of random events (ok, so they have
to
>> > cheat at dice). i realised that it would be possible to cheat in
_entirely_ the
>> > wrong way by using undo, so i disabled it (only for that puzzle). (im
using
>> > inform, so it was easy). but now i read that winfrotz undo is seperate
from
>> > the z-machine undo... so is there really nothing i can do to prevent
people
>> > cheating here?
Come on, not EVERYBODY is going to cheat on every game there is by
brute-force UNDO solving of puzzles just because it's there - it's just
handy to have UNDO when, say, in Zork Zero, the Jester comes around while
you're working on a crucial puzzle and has a bat deposit you 100,000 miles
away...
I use multi-UNDO a lot to betatest my WIP. Or to try fun stuff in
Info[co|r]m games. And that's about it.
Gunther Schmidl
To summarize the summary of the summary: People are a problem.
--
Gunther
Iain Merrick
Branko Collin wrote:
> On Thu, 28 May 1998 11:55:38 +0100, Iain Merrick <i...@cs.york.ac.uk>
> wrote:
[...]
> >> 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?
Huh? BLAZEMONGER? Is that one of the TextFire thingies (which I managed
to completely miss)? Or a real game, even?
I was actually trying to spoof _So Far_, though I couldn't remember much
about it other than that it was 'cruel'.
Darin Johnson
Iain Merrick <i...@cs.york.ac.uk> writes:
> Huh? BLAZEMONGER? Is that one of the TextFire thingies (which I managed
> to completely miss)? Or a real game, even?
You don't know BLAZEMONGER? It's the fastest game ever developed.
It's so fast, the intro sequence appears before you click on the icon.
You need a heat skink to play it on 6502's. Monitor burn-in is a
literal concern.
--
Darin Johnson
(ps: it's comp.sys.amiga.advocacy folklore)
Darin Johnson
George Caswell <timb...@wpi.edu> writes:
> It would be just as well to not let the player even -enter- the mine
> field without the map, since doing so would be patently stupid.
Quite true. However, we're assuming a perfect world, where the author
of the piece will always design their puzzles perfectly.
Also, if a game refuses to let you enter, it would seem unrealistic
and artificial. If the player doesn't know there's a map, it would be
a blatant clue that they need something, whereas if they kept blowing
up all the time, we can let their sense of induction figure this out.
Maybe just have the player always blow up, that could work; but it's
not as interesting.
(this ignores the issue that such a puzzle might not be all that
clever to start with)
> That's a
> better solution that trying to block save/restore/undo, particularly since
> there's no way you can ever keep the interpreter from letting the user
> bypass that sort of annoyance.
It depends upon the level of effort on the players part. Ie, to
do this with TADS, you'd need to dump memory, or patch a version of
the interpreter, etc. I don't think worrying about such things is
a good use of time. But it's simple enough to assume the player is
going to play normally, and thus you can disallow save/restore/undo.
(it won't work for Inform games, because interpeters that allow
save/undo independently from the game are too common)
> Your version of the puzzle demands that the only proper solution is to
> find the map to the mine field without entering it first. Disallowing
> entry to the minefield is, I'll concede, not a great solution, but
> certainly a reasonable one if you want to prevent people from mapping it
> with UNDO.
Hmm, I don't think that's what I wanted to prevent. (I just made it
up on the spot, it's not like it's in a real game) What I was thinking
of was an interesting and slightly devious twist; the payoff is that
the smart-aleck player might say "aha, I've outsmarted the author,
since I can bypass the puzzle", and then find out they can't.
It's not my business to dictate to authors what they should have in a
game. If they think a complex maze is ok, I'm not going to stand in
their way. As a *player* I may think the game sucks, but the author
has the right to add them, and the right to try and disallow certain
actions that would bypass it.
--
Darin Johnson
da...@usa.net.delete_me
Jonadab
Michael Straight <stra...@email.unc.edu> wrote in article
<Pine.A41.3.95L.98053...@login4.isis.unc.edu>...
>
>
> On Sun, 31 May 1998, Gunther Schmidl wrote:
>
> > Jonadab wrote:
> > >Actually, I allow "x all" in my game. Would that almost make up for
> > >disabling multiple-undo?
> >
> > NO!
> > I want multiple undo!
>
> I demand "undo all"!
Sure thing. I've just added the following grammar to Diary of a Text
Adventurer:
Extend "undo" first
* "all" -> Restart;
--
From 501 uses for peanut butter:
242. Use to promote international fascism.
[Insert funny quote here.]
Jonadab
Benjamin Kenward <some...@sable.ox.ac.uk> wrote in article
<6ks747$c1p$1...@news.ox.ac.uk>...
> on the subject of disabling undo... my work in progress has a puzzle in
which
> the player must influence a sequence of random events (ok, so they have
to
> cheat at dice). i realised that it would be possible to cheat in
_entirely_ the
> wrong way by using undo, so i disabled it (only for that puzzle). (im
using
> inform, so it was easy). but now i read that winfrotz undo is seperate
from
> the z-machine undo... so is there really nothing i can do to prevent
people
> cheating here?
>
>
Dunno. It may be that there is no way to prevent Frotz's (WinFrotz or
DOSFrotz -- it shouldn't matter) alt-u hotkey from working like a regular
undo. I only know how to prevent it from doing the multiple-undo. (And
this could easily be done for that puzzle only, as well.
The best thing I can figure is to set an each_turn routine in direct
context of the puzzle in question to execute @save_undo (it needs a local
variable as an argument, to which it passes a value you won't likely need
to consult). Try that.
The library does
@save_undo i;
right *after* the input is taken from the keyboard but before it is
processed. Calling it again during an each_turn routine (once processing
has begun) should *theoretically* cause a subsequent undo to resume at that
point -- after processing has been (irrevocably, then) begun. As I said,
try it and see what happens. You will need a copy of Frotz to test. The
hotkey under DOS is alt-u, but consult the documentation for whichever
version of Frotz you get.
This is not guaranteed to work until you try it. Because Frotz's behavior
is outside the specifications, controlling it is a tad bit unpredictable
unless you have the source for Frotz in front of you and understand it,
which would be a last resort you could go to to figure out how to disable
the feature by sneakily doing something Frotz doesn't expect. Hopefully
you won't need to go to that extreme.
One consequence will be that, after the puzzle in question is (fairly)
completed, the player still will not be able to multi-undo back to before
it was completed, so be aware of this. Warning the player to save right
before the undo is disabled might be a good idea.
Jonadab
Darin Johnson <da...@usa.net.removethis> wrote in article
<tvyiumm...@cn1.connectnet.com>...
> "Paul A Krueger" <WEIRD...@prodigy.net> writes:
>
> > I agree with the majority though, that I'd be highly suspicious of the
> > fairness of a puzzle that did this.
>
> Some puzzles based upon a random sequence can be solved with undo's.
> Ie, let's say you're supposed to find a map to get you through a mine
> field. The mines are placed randomly. A player without the map could
> undo everytime the character died, and move a different direction.
>
> The puzzle itself is fair, but restore/undo could bypass it.
>
> One solution is to disallow undo/save while on the minefield. Another
> that TADS allows, is to set a function hook called after restore or
> undo that will regenerate the minefield and move player to the start
> of it.
>
This could be done in Inform also. You'd have to replace the keyboard
routine, but it wouldn't be all that tricky, upon a successful (regular)
undo, to check to see if the player is on the minefield (or whatever) and
if so to call any routine you like. Frotz's multi-undo might make this a
bit trickier, though. I'm not sure if Inform is aware at all that an undo
has been performed in that case. It'd be worth checking if you were
writing that kind of puzzle.
GLEEMOTH
I just wanted to add to all this that, as far as I know, access to undo with
TADS is entirely in the hands of the author; you can take it out just by
removing undoVerb.
Shay Caron (in case you cared)
(Shay_...@letterbox.com
-or-
glee...@aol.com)
Dylan O'Donnell
gla...@NOSPAMuscom.com (David Glasser) writes:
>
> What Lucian is saying is that even if you disable the undo command,
> WinFrotz (and maybe other Frotzes) let you undo anyway. You can even do
Data point for the "other Frotzes" comment (isn't the plural of Frotz
Frotzim?) - FrotzS5, for the Psion Series 5 (excellent port, on the
whole, and much appreciated (thank you, Fre'de'ric!)) doesn't support
Ctrl-U (no Alt key on a Psion) running HHGTTG, ("No more undo information
available") but does running Anchorhead (the Inform game I happened to
have to hand), and will undo about a dozen moves back in the latter game
before running into the same error message. I'd be interested to know how
a game in which the discussed method of "disabling" undo was used would be
handled by it.
--
Dylan O'Donnell : O fuge Iabrochium, sanguis meus! Ille recurvis
Demon Internet Ltd : Unguibus, estque avidis dentibus ille minax.
Southend slave deck : Ububae fuge cautus avis vim, gnate! Neque unquam
http://www.fysh.org/~psmith/ : Faedarpax contra te frumiousus eat!
Branko Collin
On Mon, 01 Jun 1998 11:57:20 +0100, Iain Merrick <i...@cs.york.ac.uk>
wrote:
>Branko Collin wrote:
>> On Thu, 28 May 1998 11:55:38 +0100, Iain Merrick <i...@cs.york.ac.uk>
>> wrote:
[a game that won't let you stop]
>> >> [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?
>
>Huh? BLAZEMONGER? Is that one of the TextFire thingies (which I managed
>to completely miss)? Or a real game, even?
>
>I was actually trying to spoof _So Far_, though I couldn't remember much
>about it other than that it was 'cruel'.
Before I'll get into trouble with the BLAZEMONGER customer support
service department, I'll just mention their homepage:
http://www-ccsl.cs.umass.edu/~barrett/bm/Viewer_Sections/Main.HTML
--
branko collin, col...@xs4all.nl
i have been in you
you have been in me - f. zappa
David Glasser
Jonadab <jon...@bright.net> wrote:
> 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?
My feelings on the subject:
Disallowing multiple undoes would not affect me, not being a user of a
Frotz platform.
Disallowing undo (period) would annoy me.
IMHO, you should not take this into account. Write a game *you* would
enjoy writing and playing. If all of r*if loves it, so much the better.
If they don't? Too bad for us.
It's your game. I don't want you changing the way you make your game
for me.
David Glasser
Jonadab <jon...@bright.net> wrote:
> Michael Straight <stra...@email.unc.edu> wrote in article
> <Pine.A41.3.95L.98053...@login4.isis.unc.edu>...
> > I demand "undo all"!
>
> Sure thing. I've just added the following grammar to Diary of a Text
> Adventurer:
>
> Extend "undo" first
> * "all" -> Restart;
I'd check to make sure this works. UNDO is handled specially in
Keyboard (as is Restart, I think).
David Glasser
David Glasser <gla...@NOSPAMuscom.com> wrote:
> Though Inform doesn't support multiple undo in the first place.
OK, a reply to my reply, because it made me think of something
something: can you implement multiple undo in Inform? It would make
sense that, because undo restores all of memory's contents (except
transcript bit, I think) you should be able to do multiple undo. That
is, one undo should get it to the state where a previous undo can be
done.
Therefore, simply removing the blocking of multiple undo from Keyboard
should work. Why doesn't it?
Joe Mason
Branko Collin wrote:
>
> Before I'll get into trouble with the BLAZEMONGER customer support
> service department, I'll just mention their homepage:
Hey - that's "Customer Service". Don't forget the quotes. "Legal
reasons", you know.
Joe
Jonadab
David Glasser <gla...@NOSPAMuscom.com> wrote in article
<1da0co5.19n...@usol-phl-pa-142.uscom.com>...
> David Glasser <gla...@NOSPAMuscom.com> wrote:
>
> > Though Inform doesn't support multiple undo in the first place.
>
> OK, a reply to my reply, because it made me think of something
> something: can you implement multiple undo in Inform? It would make
> sense that, because undo restores all of memory's contents (except
> transcript bit, I think) you should be able to do multiple undo. That
> is, one undo should get it to the state where a previous undo can be
> done.
>
> Therefore, simply removing the blocking of multiple undo from Keyboard
> should work. Why doesn't it?
It might on Frotz, but it wouldn't on any interpreter with only one undo
save slot, because it saves over the previous slot. (The undo save slot is
outside the specs. It could be in RAM or on disk or even theoretically
tape backup (ugh), or whatever.)
However, you COULD implement multi-undo in inform. What you have to do is
have a set of arrays that can be encoded with information each time *any*
change is made to the game state, flagging exactly how to undo it. This
would be VERY tricky to work out, since you'd need a way to encode any
change that could be made. Then you never call save_undo OR restore_undo;
instead, you call MySaveUndo() and MyRestoreUndo(), which deal write and
read that array, respectively.
You might need more than one array, actually, or even a couple of dummy
objects to hold information.
--
From 501 uses for peanut butter:
275. Spread it on bread -- go figure.
L. Ross Raszewski
In article <1da0co5.19n...@usol-phl-pa-142.uscom.com>,
gla...@NOSPAMuscom.com (David Glasser) wrote:
>
> David Glasser <gla...@NOSPAMuscom.com> wrote:
>
> > Though Inform doesn't support multiple undo in the first place.
>
> OK, a reply to my reply, because it made me think of something
> something: can you implement multiple undo in Inform? It would make
> sense that, because undo restores all of memory's contents (except
> transcript bit, I think) you should be able to do multiple undo. That
> is, one undo should get it to the state where a previous undo can be
> done.
>
> Therefore, simply removing the blocking of multiple undo from Keyboard
> should work. Why doesn't it?
>
What happens to the contents of the undo buffer when the next save_undo occurs
is unspecified. the exact letter of the Z-machine can be interpreted to say
that multiple undo is acceptable, but this would cause the game state to grow
larger with each passing turn. In theory, however, two "undo" commands in
immediate succession would indeed undo two turns, if not for the fact that
inform _manually_ blocks an undo when one has just occured.
Frotz does not (unless there's a flaw in my reasoning that I can't see)
maintain its multiple undo separate of the Z-machine, it simply interprets the
spec differently from other interpreters, causing an undo to restore not only
the game, but the contents of the undo buffer. it is logically _only_ because
inform's standard libraries block undoing twice in succession that it is not
possible.
In practice....
I removed lines 646-648 of the Keyboard function in parser.h, compiled, and
executed the following:
>z [Turns=1 in the status line]
Time Passes...
>z [Turns=2 in the status line]
Time Passes...
>Undo [Turns=3 in the status line]
[Previous turn undone]
>Undo [Turns=2 in the status line]
[Previous Turn undone]
>Undo [Turns=1 in the status line]
[You can't undo what hasn't been done]
These are the effects in Frotz. In jzip, successive undoes leave the game on
turn 2.
My conclusion: Multiple undo is _NOT_ an outside system which frotz
implemenets separately. Frotz simply restores the game state when an undo
occurs, and considers its own undo buffer to be _part_ of the game state.
If you remove calls to @save_undo from inform's library, undo is not
available, even in frotz. If you add calls to @save_undo to the library,
frotz will fill its multi-undo buffer more quickly.
Alt-U undo does _not_ activate some magical outside feature, loading from an
individual, non-z buffer, it executes the opcode @restore_undo, without first
checking that an undo has occured.
L. Ross Raszewski
In article <1da0co5.19n...@usol-phl-pa-142.uscom.com>,
gla...@NOSPAMuscom.com (David Glasser) wrote:
>
> Therefore, simply removing the blocking of multiple undo from Keyboard
> should work. Why doesn't it?
About ten seconds after I posted my last reply, I found out htat my copy of
the specification of the Z machine was corrupted. It turns out that the undo
buffer is explicitly _not_ part of the game state, so considering it as such
is not spec compliant. However, it is not a violation of the spec to restore
it when executing an undo, as any behavior beyond restoring the entire game
state is unspecified.
That is to say, the spec neither says that multiple undo should work, or that
it shouldn't, but to say that frotz's ability to perform multiple undoes is
separate from thje Z-machine and therefore untouchable is wrong. Frotz does
not work separate from the spec in implementing undo, it instead works
_beyond_ the spec, implementing the full specification, then adding to it.
Therefore, any action _within the spec_ which undermines undo undermines
Frotz-undo as well.
Executing @save_undo twice in succession prevents multiple undo thus:
The first @restore_undo restores the game to the _second_ undo. A subsequent
undo restores the game to the first undo, _but_, because the game has now been
restored to a point _before_ the second undo took place, it occurs again. A
third undo will now send the game back to the second undo.
Here is what happens in practice
T=turn
T1
>Z.
T2
>z
T3
>undo ! to the _second_ undo
T2
>undo !to the _first_ undo. THe second undo now happens again -- but this
!overwrites the flag inform sets to tell if an undo has just occured, so
!inform continues processing the last command it recieved, the "z". It
executes this, time passes, and we're back on turn 3
T3
>Undo ! Back to the _second_ save_undo. this time, inform gets the flag
! indicating that the game was just undone, so it tosses out the input
T2
>Undo ! Now, the next undo in the buffer is the second undo executed on turn
! _1_.
Turn 1.
So it doens't _really_ block multiple undo, it just makes it harder. (and
_yes_, I _did_ test it.)
Andrew Plotkin
L. Ross Raszewski (rras...@hotmail.com) wrote:
> That is to say, the spec neither says that multiple undo should work, or that
> it shouldn't, but to say that frotz's ability to perform multiple undoes is
> separate from thje Z-machine and therefore untouchable is wrong.
If I appear to have said this, I apologize. I agree with your analysis,
as far as I can tell from a quick scan.
When I said "Frotz is outside the spec", I was talking about its hotkey
system, which can initiate a restore-undo action in the Z-machine even
though the Z-machine has not encountered a @restore_undo opcode.
I continue to maintain that if you put in extra @save_undo opcodes,
solely for the purpose of confusing Frotz, you are making a serious
mistake.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
L. Ross Raszewski
In article <erkyrathE...@netcom.com>,
erky...@netcom.com (Andrew Plotkin) wrote:
>
> L. Ross Raszewski (rras...@hotmail.com) wrote:
>
> > That is to say, the spec neither says that multiple undo should work, or
that
> > it shouldn't, but to say that frotz's ability to perform multiple undoes
is
> > separate from thje Z-machine and therefore untouchable is wrong.
>
> If I appear to have said this, I apologize. I agree with your analysis,
> as far as I can tell from a quick scan.
>
> When I said "Frotz is outside the spec", I was talking about its hotkey
> system, which can initiate a restore-undo action in the Z-machine even
> though the Z-machine has not encountered a @restore_undo opcode.
>
> I continue to maintain that if you put in extra @save_undo opcodes,
> solely for the purpose of confusing Frotz, you are making a serious
> mistake.
>
single you out generally). Moreover, I completely agree. aside from slowing
down the game, this method just plain doesn't _work_, as repeated undos will
still nudge the game back a few turns.
But here's a trick that _will_ work:
instead of doubling up the @save_undo i; line, declare a new loval variable, j
and do this:
change @save_undo i; to the following:
@save_undo j;
i=j;
while (j==2) { i=j; @save_undo j; }
THis causes a second save_undo to occur _only_ when restoring an undo, and
completely blocks (afaict) multiple undo
Andrew Plotkin
L. Ross Raszewski (rras...@hotmail.com) wrote:
> But here's a trick that _will_ work:
> instead of doubling up the @save_undo i; line, declare a new local
> variable, j and do this:
>
> change @save_undo i; to the following:
>
> @save_undo j;
> i=j;
> while (j==2) { i=j; @save_undo j; }
>
> THis causes a second save_undo to occur _only_ when restoring an undo, and
> completely blocks (afaict) multiple undo
I continue to maintain that if you put in extra @save_undo opcodes,
solely for the purpose of confusing Frotz, you are making a serious
mistake.
--Z
Phil Goetz
In article <01bd8ba0$e6ad7ec0$0a118fd1@jonadab>,
Jonadab <jon...@bright.net> wrote:
>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.
Games are made challenging by having puzzles that require thought.
Multiple undo doesn't make thinking any easier.
Perhaps the puzzles, and not undo, are the problem.
Phil Go...@zoesis.com
Mark J. Tilford
ba1$de24ef80$0a118fd1@jonadab> <1d9ut4b.oa...@usol-phl-pa-053.uscom.com> <1da0co5.19n...@usol-phl-pa-142.uscom.com> <6l2j03$uie$1...@nnrp1.dejanews.com>
Reply-To: til...@cco.caltech.edu
Followup-To:
On Wed, 03 Jun 1998 04:21:23 GMT, L. Ross Raszewski <rras...@hotmail.com> wrote:
>If you remove calls to @save_undo from inform's library, undo is not
>available, even in frotz. If you add calls to @save_undo to the library,
Can't frotz do multiple undo even on v3 games? How does it do that if
there isn't an @save_undo call in those games?
--
-----------------------
Mark Jeffrey Tilford
til...@cco.caltech.edu
L. Ross Raszewski
In article <slrn6neked....@ralph.caltech.edu>,
til...@ralph.caltech.edu (Mark J. Tilford) wrote:
>
> ba1$de24ef80$0a118fd1@jonadab>
<1d9ut4b.oa...@usol-phl-pa-053.uscom.com>
<1da0co5.19n...@usol-phl-pa-142.uscom.com>
<6l2j03$uie$1...@nnrp1.dejanews.com>
> Reply-To: til...@cco.caltech.edu
> Followup-To:
>
> On Wed, 03 Jun 1998 04:21:23 GMT, L. Ross Raszewski <rras...@hotmail.com>
wrote:
> >If you remove calls to @save_undo from inform's library, undo is not
> >available, even in frotz. If you add calls to @save_undo to the library,
>
> Can't frotz do multiple undo even on v3 games? How does it do that if
> there isn't an @save_undo call in those games?
>
In v3 games, frotz supports undo
in v5 games supporting UNDO, frotz supports undo -- and does it with the same
effect as having typed "UNDO"
in v5 games not supporting undo, frotz can't undo.
My conclusion is that frotz _does_ insert a save undo itself, ONLY for v3 (and
v4) games. if a v5+ game does not support undo (hitchhiker's guide to the
galaxy) you're screwed.
To test this hypothesis, I removed the @save_undo line from parserm.h,
compiled and ran. Undo didn't work.
So, perhaps frotz does use a separate facility, but _only_ when pkaying a
pre-v5 game.
Paul O'Brian
On Mon, 1 Jun 1998, Darin Johnson wrote:
> Iain Merrick <i...@cs.york.ac.uk> writes:
>
> > Huh? BLAZEMONGER? Is that one of the TextFire thingies (which I managed
> > to completely miss)? Or a real game, even?
>
> It's so fast, the intro sequence appears before you click on the icon.
> You need a heat skink to play it on 6502's.
As long as I don't have to kill the heat skink. That would just go against
my principles.
Paul O'Brian
obr...@colorado.edu
http://ucsu.colorado.edu/~obrian
Roger Carbol
L. Ross Raszewski wrote:
> My conclusion is that frotz _does_ insert a save undo itself, ONLY for v3 (and
> v4) games. if a v5+ game does not support undo (hitchhiker's guide to the
> galaxy) you're screwed.
Not exactly. The painful workaround is to save the game every turn and
then load it when you want to undo the last move. This method also
clearly supports multiple undo's to any desired level.
.. Roger Carbol .. r...@shaw.wave.ca .. undo voodoo