Inform: Blocking "undo" command
Sam Hulick
Is there some nice&neat way I can block the "undo" command (without
editing the library) when I release my game? Personally, I think undo
is a bit cheap and should be used for debugging only.
P.S.: Gareth, if you're reading this, can you post or email that
parser.h patch ("all" bug) again? Thanks
--
--- Sam Hulick ------------- shu...@indiana.edu ---------------------
Systems Consultant | Homepage:
Indiana College Placement | http://copper.ucs.indiana.edu/~shulick/
and Assessment Center | PGP public key available on request
Gerry Kevin Wilson
Personally, I allow as much undoing as TADS supports, including undo upon
death. I even made an easy death module that allows you to undo after
death with two keystrokes. Why? Ease of use. There are rather a lot of
ways to die in Avalon, and there's no need for me to add insult to
injury. So the player doesn't have to build up a huge pile of save games
and remember which was which. Avalon even warns the player if the game
has reached an unwinnable state.
[The game has reached an unwinnable state. Perhaps you would
like to undo that last move?]
These two things are pet peeves for me, so I worked around them. But
hey, if any player playing Avalon wants to use save/restore instead of
undo, I'm not stopping them. If they wish to forge on knowing the game
is unwinnable, more power to them. I just make them aware of their options.
--
<~~~VERTIGO~~~~~~~~~~~~THE~BRASS~LANTERN~~~~~~ISSUE~1~INCL~W/AVALON~~|~~~~~~~>
< In the irreverent tradition of _The New Zork Times_ comes The | ~~\ >
< Brass Lantern, an informative newsletter from Vertigo Software. | /~\ | >
<___SOFTWARE____________...@uclink.berkeley.edu__|_\__/__>
Jason Compton
: I want to know your folks' opinions. Do you think the "undo" feature is
: considered cheating? Personally, I do. What is the point if they can
: just undo a silly move--say they get killed by some creature because
: they stole his food unknowingly. They can just say "oops!" and type
: "undo" and this, IMO, eliminates the whole point of the puzzles of
: So will blocking "undo" in my game attract fewer people? Will people
: say "Oh, then I'm not going to play THAT game."? What are your opinions
: on this matter? If one removes "undo" from their game, should they
: remove "restore" as well? Are they similar? If enough people think
: games should have "undo", I will probably leave it in. I am only
: slightly inclined to remove it.
It's your work, you have the final say as to how it will be played. If
you think your universe is one where life shouldn't be quite so
forgiving, then it's your choice and the players have to abide by it.
However, "undo" is just an easier way to avoid saving after every move,
and in this day and age of flexible interpreters, there's no 4 or 8-slot
save limit, so a player could just as easily save after every move and
restore it. Eliminating the save/restore feature is absolutely brutal.
Plus, there's also something to consider-puzzles are not necessarily less
fun if there is little or no risk involved. While not true IF, Day of
the Tentacle is unloseable-you cannot do anything that will come back to
haunt you later on. It's still rather fun, even if it at times turns
into a silly "Use X with Y" fest, trying to find a match.
--
Jason Compton jcom...@xnet.com
Editor-in-Chief, Amiga Report Magazine (708) 741-0689 FAX
You've got to go faster than that. Better start doing it right.
AR on Aminet - docs/mags/ar???.lha AR Mailing list - Mail me
AR on WWW - http://www.omnipresence.com/Amiga/News/AR
Sam Hulick
I want to know your folks' opinions. Do you think the "undo" feature is
considered cheating? Personally, I do. What is the point if they can
just undo a silly move--say they get killed by some creature because
they stole his food unknowingly. They can just say "oops!" and type
"undo" and this, IMO, eliminates the whole point of the puzzles of
having to restore a game that would require a few minutes of work to get
back to where they were when they died. "Undo" was never available in
the earlier Infocom games (Sorcerer, Zork I, Wishbringer, etc.) and no
one complained about it. They were very fun, addictive, and involving.
On my game, I plan to block the "undo". I don't want people getting out
of sticky situations that easily.
So will blocking "undo" in my game attract fewer people? Will people
say "Oh, then I'm not going to play THAT game."? What are your opinions
on this matter? If one removes "undo" from their game, should they
remove "restore" as well? Are they similar? If enough people think
games should have "undo", I will probably leave it in. I am only
slightly inclined to remove it.
Thanks for your input.. :)
Carl Muckenhoupt
>I want to know your folks' opinions. Do you think the "undo" feature is
>considered cheating? Personally, I do. What is the point if they can
I do not. "Undo" gives the player no capabilities that are not already
provided by "save game". It just makes things a little more convenient.
>just undo a silly move--say they get killed by some creature because
>they stole his food unknowingly. They can just say "oops!" and type
^^^^^^^^^^^^^^^^^^^^^^^^^^
This is called Death Without Warning. Many of us consider it to be a Bad
Thing.
>"undo" and this, IMO, eliminates the whole point of the puzzles of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There's more to puzzles than annoyance. The point of puzzles, IMHO, is
the way they involve the player. You are actively involved in tinkering,
experimenting, trying to figure things out. Replaying a part of the game
you've already seen does not enhance this. "Undo" is a tool that gets
some of the inconvenience out of the way so you can concentrate on the
heart of the puzzle instead.
>interactive fiction. Part of the "being stumped" is getting killed and
>having to restore a game that would require a few minutes of work to get
>back to where they were when they died. "Undo" was never available in
>the earlier Infocom games (Sorcerer, Zork I, Wishbringer, etc.) and no
>one complained about it. They were very fun, addictive, and involving.
^^^^^^^^^^^^^^^^^^^^^^^
No one complained that you had to play them off of floppies, either. We
didn't know any better. Being hard-disk installable is a convenience
that can only improve a game. The "undo" command is another. I'm sure the
games you cite would have included "undo" in their first release if they
could have done so. Yes, they were fun, addictive, and involving without
"Undo." They're also fun, addictive, and involving with "undo" (as in
later releases.)
>On my game, I plan to block the "undo". I don't want people getting out
>of sticky situations that easily.
>So will blocking "undo" in my game attract fewer people? Will people
>say "Oh, then I'm not going to play THAT game."? What are your opinions
>on this matter? If one removes "undo" from their game, should they
>remove "restore" as well? Are they similar? If enough people think
>games should have "undo", I will probably leave it in. I am only
>slightly inclined to remove it.
If you disable "undo", I will still play your game. I have played enough
games without "undo" that it doesn't bother me. But the thing is, "Undo"
is more a part of the user interface than a part of the game. The
content of the game - the fictional world we glimpse through the screen -
knows nothing about it. It's like having an on-screen map, or mouse
support, or something. Disabling it won't make it the game any better or
worse, any more than chess is a better game when played with wooden
pieces than when played with plastic pieces.
NB: Big exception. Some puzzles absolutely require locking the player
into the game for a short while. An example is the cubes in the vault in
"Spellbreaker." You have to solve that puzzle, from start to finish,
without any of the information you can get by guessing wrong and trying
again. During that time, you can neither undo nor save your game. This
is acceptable, because it's only for a short time and because the puzzle
really demands it.
--
Carl Muckenhoupt | Is it true that Kibo habitually autogreps all of Usenet
b...@tiac.net | for his name? If so: Hi, Kibo. Like the sig?
Dan Shiovitz
Sam Hulick <shu...@mango.ucs.indiana.edu> wrote:
>
>I want to know your folks' opinions. Do you think the "undo" feature is
>considered cheating? Personally, I do. What is the point if they can
>they stole his food unknowingly. They can just say "oops!" and type
>"undo" and this, IMO, eliminates the whole point of the puzzles of
>interactive fiction. Part of the "being stumped" is getting killed and
The point of puzzles are to annoy people?
>having to restore a game that would require a few minutes of work to get
>back to where they were when they died. "Undo" was never available in
(Debatable)
>the earlier Infocom games (Sorcerer, Zork I, Wishbringer, etc.) and no
>one complained about it. They were very fun, addictive, and involving.
True, but possibly that's just a matter of technology. No one complained
about the poor parser in Scott Adams games, yet anyone trying to get by
with that sort of parser today would find themselves player-less.
>On my game, I plan to block the "undo". I don't want people getting out
>of sticky situations that easily.
Maybe. OTOH, what if someone thoughtlessly mistypes something. Should they
be killed for that?
Example:
There is a nuclear bomb, a macintosh, and a mcintosh here.
The macintosh is about to run the virus program ...
>GET BOMB. THROW IT AT MCINTOSH.
The apple explodes! Oops. The computer completes the virus program. You
lose.
> OOPS MACINTOSH
Haha, too late.
Well, perhaps not this silly, but I think you get the point. I don't see
anything wrong with allowing the undo command. One fairly common solution
to your problem that I've seen is not to allow undos after a death, but only
allow them in-game. (There are, I agree, puzzles where it ruins the puzzle
to allow undos. Example, the three-doors-one-of-which-has-a-tiger-behind-it
sort of puzzle. But perhaps you could just restrict undos in those
circumstances, or just not have those sort of puzzles!)
>So will blocking "undo" in my game attract fewer people? Will people
>say "Oh, then I'm not going to play THAT game."? What are your opinions
>on this matter? If one removes "undo" from their game, should they
>remove "restore" as well? Are they similar? If enough people think
>games should have "undo", I will probably leave it in. I am only
>slightly inclined to remove it.
I doubt anyone will not play your game because you took out undo. Nobody would
stop playing a game that didn't have the "oops" command either. Still, it's
a nice thing to have. (I even found a game on the archive that didn't allow
save/restore, and stuck that out to completion. But it was a pretty good
game.)
> Thanks for your input.. :)
>--- Sam Hulick ------------- shu...@indiana.edu ---------------------
--
------------------------------------------------+--------------
The Grim Reaper ** scy...@u.washington.edu |
Dan Shiovitz ** sh...@cs.washington.edu | Aude
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Sapere
_Music of the Spheres_ : Coming Nov '95 |
------------------------------------------------+--------------
Andrew C. Plotkin
(one-move) silly or dangerous things in a game, because I know I can
jump back. (And in games with multiple undo, I go farther, although
actually at that point I probably just save.)
If I find myself wanting to type "undo", but it doesn't work in your
game, then I have to go back to an earlier saved game and replay part of
the game that I've already gone through. I'm not doing it by choice; I'm
doing it because I have to. Thus, I am probably bored. Your game is
boring me for those couple of minutes. Do you want your game to bore me?
Any puzzle which is ruined by the existence of "undo" is also ruined by
the existence of "save". We have ten years of experience in how to
construct puzzles which don't have this problem. If you want to put one
in, suppress "undo" and "save" for the duration of that scene only.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
Mark Green
shu...@mango.ucs.indiana.edu "Sam Hulick" writes:
>
> I want to know your folks' opinions. Do you think the "undo" feature is
> considered cheating? Personally, I do. What is the point if they can
> just undo a silly move--say they get killed by some creature because
> they stole his food unknowingly. They can just say "oops!" and type
> "undo" and this, IMO, eliminates the whole point of the puzzles of
> interactive fiction. Part of the "being stumped" is getting killed and
> having to restore a game that would require a few minutes of work to get
> back to where they were when they died.
This seems to imply that the point of any puzzle in an IF game is to
avoid being killed - this isn't the case! Does a locked door kill you if
you don't open it? No, of course not - yet that puzzle will still be solved
because it holds the promise of discovering a new area.
Take Theatre as an eaxmple. I can only think of a few ways of getting
killed in that game, and only one of those is truly Death Without Warning
(the snoring pit monster) and they can all be undone. But if you DO undo
in one of those situations, you're still just as stuck as you were before.
In the example above - ok, so a creature kills you for stealing its food.
But if you undo, you're still without the food, and you haven't gained
any real help with the puzzle by coming back from the dead. Without an
undo, the person has to start again from their last save point, go through
everything up to that puzzle again, except this time, they will save
there. Then they'll have a virtual undo just by restoring their game - the
only exception is that they will have had to go through more hassle to get
it. In that sense, you can't really block "undo" without blocking "save".
And if you block save, your game will probably not be played much because
there will be some meridian where the poor player will have to do more work
to get back to the place (s)he left off at last time than to solve the next
puzzle!
Mg
--
Gareth Rees
> Is there some nice&neat way I can block the "undo" command (without
> editing the library) when I release my game? Personally, I think undo
> is a bit cheap and should be used for debugging only.
You need to `Replace' the `PlayTheGame' and `Keyboard' routines from
`parser.h'; just copy out the code and delete the bit that deals with
undoing.
A hackish alternative is to write:
[ TimePasses; undo_flag = 0; ];
but that won't stop a player undoing after death.
Having said that, `undo' is not cheap. It is an interface feature
rather than a game feature (would you say that `inventory' is cheap
because the player can always remember what he or she has picked up?)
and it makes a game a lot more pleasant to play. In any case it is a
feature that can be added to an interpreter without the knowledge of a
game file, or simulated through careful and very tedious use of saved
games.
> P.S. Gareth, if you're reading this, can you post or email that
> parser.h patch ("all" bug) again? Thanks.
Add the following before line 1602:
if (token > 1 && token < 6 && multiple_object-->0 > 1)
multi_context = token;
and the following before line 852:
multi_context = 0;
However, Graham tells me that he has a better fix which will be in
release 5/12 of the library.
--
Gareth Rees
Christopher E. Forman
: If I die, I usually type "undo". In fact, I'm willing to do all sorts of
: (one-move) silly or dangerous things in a game, because I know I can
To me, "undo" is more of a time-saver than a cheat. It's like having the
game automatically saved on every move. I don't know about some players,
but for me it's annoying to have to restore (or restart, if I haven't saved)
just because I made one mistake. For me, an "undo" command is indispensible.
For an interesting twist on "undo," you'd do well to check out my game, "The
Path to Fortune" (due out soon, I promise!). It includes not only the
standard "save" and "undo" commands, but also a new feature I like to call
"Warning Mode." When active (and it IS optional), the game tells you when
you enter a situation in which you may become permanently stuck, thus
allowing you to "undo" and then "save" before proceeding. It doesn't work
for every single thing (that would be too easy), but it does serve to
reduce frustration caused by players getting stuck through no fault of their
own.
--
C.E. Forman cef...@rs6000.cmp.ilstu.edu
Read the I-F e-zine XYZZYnews, at ftp.gmd.de:/if-archive/magazines/xyzzynews!
* Interactive Fiction * Beavis and Butt-Head * The X-Files * MST3K * C/C++ *
Neil Demause
: allow them in-game. (There are, I agree, puzzles where it ruins the puzzle
: to allow undos. Example, the three-doors-one-of-which-has-a-tiger-behind-it
: sort of puzzle. But perhaps you could just restrict undos in those
: circumstances, or just not have those sort of puzzles!)
Please, please, don't have these sorts of puzzles! (If "puzzles" even
applies to this sort of thing.)
Really, it isn't hard to avoid this problem -- if you don't want the
player to be able to try all the available options, just make more
options than they're willing to try. (The many-bolted door in Veritas
comes to mind.)
IMHO, any puzzle with so few options that trial-and-error would solve it
is solvable by a lucky guess, which isn't much of a puzzle to me.
Magnus Olsson
Neil Demause <ne...@echonyc.com> wrote:
>
>Really, it isn't hard to avoid this problem -- if you don't want the
>player to be able to try all the available options, just make more
>options than they're willing to try. (The many-bolted door in Veritas
>comes to mind.)
>
>IMHO, any puzzle with so few options that trial-and-error would solve it
>is solvable by a lucky guess, which isn't much of a puzzle to me.
The problem with this is that some players are willing to go to
amazing lengths when it comes to trial-and-error. When you're sufficiently
frustrated, trying all the 297 doors, behind 296 of which a tiger lurks,
does seem preferable to doing nothing.
So to prevent solution by trial-and-error, there should at least be a
couple of thousand alternatives, which in many situations would be rather
contrived, not to speak of the difficulties of implementing it.
In "Dunjin", I have two problems that could in principle be solved
by trying a rather limitde number of possibilities.
The first is guessing the name of the dwarf. I "solved" this by Sam's
method: killing the player off if he makes a wrong guess. Dunjin
doesn't have any undo capability, and there are eight or nine
alternatives (once you've understood the clue), but I wouldn't bet that
there aren't players who've solved that puzzle by brute force.
Today, I'd never code a puzzle like that. Maybe I'd put bopth the
dwarf and the clues to his names in a "no saving allowed" area and
have his name be randomly selected each time the player enters the
area.
The second problem is identifying the demon. There is a canonical way
of identifying him with 100% certainty, but even if you don't find
that you have a list of demon names to try. In this problem, I simply
let the demon know whether you're just guessing (i.e. trying names at
random from the list) or if you really know. IMHO this is a preferable
solution, but it can't always be applied.
Magnus