How important is UNDO?
Eric O'Dell
Here's a question I'd like to get everyone's opinion on ---
Just how important is UNDO? Is it a convenience, or is it essential,
i.e., would you consider a runtime system without UNDO to be crippled
or unusable?
--Eric
+-------------------------------------------------------------------+
| "I have come a very long way from myself only to realize that |
| identity is a skill and self-betrayal is a habit. Once lost, the |
| former is very hard to regain; once gained, the latter is very |
| hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
+-------------------------------------------------------------------+
Dan Shiovitz
In article <35949179...@enews.newsguy.com>,
Eric O'Dell <er...@gadgetguru.com> wrote:
>Here's a question I'd like to get everyone's opinion on ---
>
>Just how important is UNDO? Is it a convenience, or is it essential,
>i.e., would you consider a runtime system without UNDO to be crippled
>or unusable?
Well. I actually played a mid-sized game all the way through that not
only didn't support undo, it didn't support save/restore unless you
had registered it (and, needless to say, I hadn't). But this was a
pretty good game, and I was playing it when I was young and it was
summer vacation, and had a lot of free time. If you're asking "I'm
writing a new IF system; do I need to go through the effort of
adding undo functionality to it?" the answer is yes, you do.
>--Eric
--
Dan Shiovitz || d...@cs.wisc.edu || http://www.cs.wisc.edu/~dbs
"...Incensed by some crack he had made about modern enlightened
thought, modern enlightened thought being practically a personal buddy
of hers, Florence gave him the swift heave-ho and--much against my
will, but she seemed to wish it--became betrothed to me." - PGW, J.a.t.F.S.
A. DeLisle
In rec.games.int-fiction Eric O'Dell <er...@gadgetguru.com> wrote:
:EO> Just how important is UNDO? Is it a convenience, or is it essential,
:EO> i.e., would you consider a runtime system without UNDO to be crippled
:EO> or unusable?
Having played most of my playing life (18 years) without it, I consider
it a convenience. Normally, I just save before taking a drastic step
and then restore. There are times when UNDO is useless. I am not sure
which recent game it was, but UNDO produced death every time.
Eric O'Dell
On 25 Jun 1998 19:34:14 GMT, d...@mozzarella.cs.wisc.edu (Dan Shiovitz)
wrote:
> If you're asking "I'm
>writing a new IF system; do I need to go through the effort of
>adding undo functionality to it?" the answer is yes, you do.
Actually, that's not what I'm asking. It's just that in the system I'm
planning, which involves executable machine code rather than a runtime
intepreter, maintaining undo information for custom objects requires
one of the following:
1) Using API calls to manage variables in a memory region that the
system keeps track of, or
2) Keeping track of your own undo information (which may be necessary
in many cases).
The extra flexibility that the system is designed to provide comes at
the cost of some extra effort, and I'm basically a little leery of the
possibility that some user, somewhere down the road, will do a crummy
job of things and it will reflect badly on the system.
>Well. I actually played a mid-sized game all the way through that not
>only didn't support undo, it didn't support save/restore unless you
>had registered it (and, needless to say, I hadn't). But this was a
>pretty good game, and I was playing it when I was young and it was
>summer vacation, and had a lot of free time.
Just wondering. I've never actually used UNDO; I find frequent saves
to be somewhat less jarring to the illusion of reality than UNDO, but
that may just be me.
JID
>Just wondering. I've never actually used UNDO; I find frequent saves
>to be somewhat less jarring to the illusion of reality than UNDO, but
>that may just be me.
Nicely put. That's exactly how I feel. I think because with save/restore,
you can't help but come all the way out of the game and then go back in,
when fiddling with filenames and so forth, whereas with undo it's as
though your character has this magic ability to mess with reality for a
minute or so. I can't think of another one-word command (like look,
inventory, etc.) that has such a strange effect on game-play immersion.
I've used it, but I almost never think to use it.
--
Johanna (aka Joey): ow...@best.com
-------------------------------------------------------
"They honed his instinct for the jugular of weakness.
It got so sharp that sometimes he couldn't look at
himself in the mirror."
-- James Ellroy, "L.A. Confidential"
------------------------------------------------------
Rosencrantz and Guildenstern In Wonderland, American
Gothic, Jeunet & Caro: http://www.best.com/~owls
-------------------------------------------------------
Mikko P Vuorinen
There were times when loading a saved game took a long time, especially
from a cassette, so UNDO and RAM SAVE were essential. But now I hardly
ever use UNDO, I just restore. In fact, I feel like using UNDO somehow
spoils the atmosphere, but restoration does not.
--
)))) (((( + Mikko Vuorinen + mvuo...@cc.helsinki.fi
)) OO `oo'((( + Dilbon@IRC&ifMUD + http://www.helsinki.fi/~mvuorine/
6 (_) ( ((( + GSM 050-5859733 +
`____c 8__/((( + + Did you see that?
Toby Franklin
Eric O'Dell (er...@gadgetguru.com) wrote:
: Here's a question I'd like to get everyone's opinion on ---
: Just how important is UNDO? Is it a convenience, or is it essential,
: i.e., would you consider a runtime system without UNDO to be crippled
: or unusable?
: --Eric
: +-------------------------------------------------------------------+
: | "I have come a very long way from myself only to realize that |
: | identity is a skill and self-betrayal is a habit. Once lost, the |
: | former is very hard to regain; once gained, the latter is very |
: | hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
: +-------------------------------------------------------------------+
I'm assuming you mean 'undo' with TADS. I think it really depends on what
kind of game you're writing, and how hard you want it to be. Many times
humourous games have undo built in during play, and when you die. This is
because (at least in my opinion), the game wouldn't be too funny anymore
if undo wasn't there, instead the game would be frustrating. However, if
you're doing a challenging game, I would remove 'undo'. You see, if a game
is hard enough, players will use 'undo' to find easy ways to get further,
therefore destroying what you're trying to accomplish.
--Toby
Darin Johnson
er...@gadgetguru.com (Eric O'Dell) writes:
> Actually, that's not what I'm asking. It's just that in the system I'm
> planning, which involves executable machine code rather than a runtime
> intepreter, maintaining undo information for custom objects requires
> one of the following:
If you can do a save, you can do an undo (I hope you weren't planning
on an emacs style dump to do saves).
If saves/restores are painful, then undo is very important. The
easier it is to save, the less importance undo has. (ie, if the
system requires me to type in the filename each time, or navigate some
gooey browser, I'd rather use undo) On the other hand, if undo is
really good, I may save less often.
I find many games without undo to be very annoying though (and yes,
that includes many the infocom games). It's just a matter of how much
annoyance to put up with. However, for someone designing a NEW system
to ask if they can design a system that will be annoying, well, that's
just even more annoying :-)
--
Darin Johnson
da...@usa.net.delete_me
Michael Straight
On Thu, 25 Jun 1998, JID wrote:
> In article <3592caa5...@enews.newsguy.com>, er...@gadgetguru.com wrote:
>
> >Just wondering. I've never actually used UNDO; I find frequent saves
> >to be somewhat less jarring to the illusion of reality than UNDO, but
> >that may just be me.
>
> Nicely put. That's exactly how I feel. I think because with save/restore,
> you can't help but come all the way out of the game and then go back in,
> when fiddling with filenames and so forth, whereas with undo it's as
> though your character has this magic ability to mess with reality for a
> minute or so. I can't think of another one-word command (like look,
> inventory, etc.) that has such a strange effect on game-play immersion.
> I've used it, but I almost never think to use it.
I can understand that. But in most games I often get the urge to try
something that I wouldn't want my character to do but that I'd like to see
how the game would react to it anyway. In that case, I've already kind of
broken mimesis myself and UNDO is much more convenient than save and
restore.
There are some bizarre, seemingly self-destructive things I never tried in
various Infocom games because it wasn't worth the bother of saving and
restoring first.
So as an artist, if you're planning to put in lots of clever responses to
actions which would prevent the player from winning (I wonder what would
happen if I gave my lamp to the troll?), then including UNDO may increase
the chances that players will actually see your hard work.
SMTIRCAHIAGEHLT
okbl...@usa.net
In article <35949179...@enews.newsguy.com>,
er...@gadgetguru.com wrote:
>
> Just how important is UNDO? Is it a convenience, or is it essential,
> i.e., would you consider a runtime system without UNDO to be crippled
> or unusable?
>
I'd like to see an entire genre of games arise that didn't require it.
Something we discussed here before was the "real-life undo", where you can't
actually go back in time and play the turn over again, but must use the same
means you would use in real life to undo a bad action. (Death is
problematic.)
I would say UNDO in the form of save-points would be a reasonable alternative
to the UNDO of today, which I could see being very difficult to implement for
certain systems. In other words, the author specifies points during the game
where the game saves its state automatically, and an UNDO takes the player
back to those points.
My opinion may not be widely shared. :-)
[ok]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
KTyers1951
Don't know what everyone else thinks, but personally I don't use UNDO even if
it's there - I forget it's there half the time.....
Todd Baumann-Fern
I agree with this. I never use the UNDO command. Isn't taking chances one of
the ideas of playing a game? I always liked the "oops" feature in some IF
though.
John Francis
In article <3592caa5...@enews.newsguy.com>,
Eric O'Dell <er...@gadgetguru.com> wrote:
>
>Just wondering. I've never actually used UNDO; I find frequent saves
>to be somewhat less jarring to the illusion of reality than UNDO, but
>that may just be me.
I find UNDO to be useful in situations where mimesis is already broken.
A (trivial) example: I try and put something in a container, and I get
a snide comment about having to open the container first. I (the player)
know that - I'd just forgotten that the container was closed. In a real
situation this wouldn't occur; it only happens in the IF game because
of the bandwidth limitations of the interface. (I used to have similar
problems with rogue, when you could ruin objects by accidentally using
them as weapons. Another bandwidth-induced problem).
Obviously I'd never actually use UNDO just to open a container, but if
you are in a time-critical section of the game and you accidentally do
something 'out of character' UNDO is the perfect remedy.
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Hello. My name is Darth Vader. I am your father. Prepare to die.
Julian Fleetwood
Eric O'Dell wrote in message <35949179...@enews.newsguy.com>...
>Here's a question I'd like to get everyone's opinion on ---
>
>i.e., would you consider a runtime system without UNDO to be crippled
>or unusable?
I don't think I've ever used UNDO that much, but if I did I think that it
would be important that the system had multiple UNDO.
Julian Fleetwood
--
Keen supporter of the 'Train Spotting as an Olympic sport' campaign
Home Page: http://www.tip.net.au/~mfleetwo/index.htm
Interactive Fiction Dimension: http://www.tip.net.au/~mfleetwo/if/if.htm
Comic Book Guy Page: http://www.tip.net.au/~mfleetwo/cbg/comic.htm
Trevor Barrie
In article <35949179...@enews.newsguy.com>,
Eric O'Dell <er...@gadgetguru.com> wrote:
>Just how important is UNDO? Is it a convenience, or is it essential,
>i.e., would you consider a runtime system without UNDO to be crippled
>or unusable?
Yes. That applies to runtime systems which only support single-turn undo,
as well.
Darin Johnson
okbl...@usa.net writes:
> I'd like to see an entire genre of games arise that didn't require it.
But no game *requires* undo. It's a player convenience - I rank
it up there with command history and "g" aliased to "again".
Why do authors hate undo so much? Why is there even a discussion
about getting rid of it ? Yes, I know, because someone thought it
would be had to implement, but I've heard plenty of people talk about
eliminating it in situations where it is already implemented.
If players hate it, they don't have to use it. But if an author goes
out of their way to remove it, it's insulting to me. It's like saying
"I want to make your life hard", because that's exactly what happens.
Undo is just a simple and quick way to save/restore the game. I can
see no logical reason to get rid of it, other than author arrogance
("how dare they get past my fiendish deathtrap with a mere undo").
> Something we discussed here before was the "real-life undo", where you can't
> actually go back in time and play the turn over again, but must use the same
> means you would use in real life to undo a bad action. (Death is
> problematic.)
Yes, death is problematic. What do you think undo is for? Actions
that inalterably change the game are problematic! If you new
something might be dangerous or unalterable, one could save - but
*usually* one doesn't know. One wouldn't expect that opening the
jeweled egg messes you up, so one might not save the game beforehand.
Yes, if you can design a game where I will never feel the need to
use undo, then great, do it, and I will support you. But I've run
across very very few games where I did not feel the need for an undo
now and then. I've run across a few where even multiple undos were
very helpful (because a single undo didn't fix things).
But *write* those games, don't remove undo instead! And after you've
written such a game, you will have no need figure out convoluted
schemes to disable undo, because in such a well designed game no
player would use it anyway.
Sheesh. Sorry for going off the deep end, I like playing these
games, but I don't like struggling with them.
--
Darin Johnson
da...@usa.net.delete_me
L. Ross Raszewski
In article <6n0p5j$kh3$1...@nnrp1.dejanews.com>,
okbl...@usa.net wrote:
>
> In article <35949179...@enews.newsguy.com>,
> er...@gadgetguru.com wrote:
> >
> > Just how important is UNDO? Is it a convenience, or is it essential,
> > i.e., would you consider a runtime system without UNDO to be crippled
> > or unusable?
> >
>
> actually go back in time and play the turn over again, but must use the same
> means you would use in real life to undo a bad action. (Death is
> problematic.)
>
> to the UNDO of today, which I could see being very difficult to implement for
> certain systems. In other words, the author specifies points during the game
> where the game saves its state automatically, and an UNDO takes the player
> back to those points.
>
> My opinion may not be widely shared. :-)
Well... if multiple turn-level undo was not available, I think "checkpoint"
undo would be a nice alternative, though I wouldn't just go willy-nilly
abandoning undo for it. One of the exptensions I'd like to see in an IF
system is a multiple-slot author-definable "redo", which would allow you to
(say) have an undo to immediately before rendering hte game unsolveable, or
allow a feature like the "flashback" mode in "Shivers". In Z, the thing you
speak of would be trivial to implement; simply remove the @save_undo opcode
from the keyboard function, and insert it at your chosen "checkpoints". Of
course, only the frotzen would support multiple-level undo.
Personally, I would like to see both abilities available concurrently.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Eric O'Dell
On Fri, 26 Jun 1998 04:24:36 GMT, Darin Johnson
<da...@usa.net.removethis> wrote:
>er...@gadgetguru.com (Eric O'Dell) writes:
>
>> Actually, that's not what I'm asking. It's just that in the system I'm
>> planning, which involves executable machine code rather than a runtime
>> intepreter, maintaining undo information for custom objects requires
>> one of the following:
>
>If you can do a save, you can do an undo (I hope you weren't planning
>on an emacs style dump to do saves).
At present, I'm planning for the save routine to compare the current
state of variable data to the starting state stored in the game file,
writing the differences to the save file. I dunno what emacs does,
besides acting as an object lesson in over-engineering.
Undo, at least as I've been thinking of it, is a very different affair
from saving. The best way I can think of to handle undo is to maintain
a linked list of actions that must be executed to backtrack to a
previous state, e.g. a player command that changes the value of
variable x from 52 to 67 creates a series of undo commands something
like
set addr x to 52
[followed by many instructions to roll back daemons and fuses]
decrement turn counter
Which is no biggie. However, CAVE is going to generate actual
executable code rather than bytecode for a virtual machine, so this
involves involves explicitly storing undo information if you add some
special routine that won't fit into the API's scheme of supported
types and data structures. I can see this being a real nightmare if
the special routine you implemented involved some relatively complex
AI subsystem.
Mind you, it's not that I object to tedious coding, it's the prospect
of running memory consumption up to outrageous levels in certain
cases.
>If saves/restores are painful, then undo is very important. The
>easier it is to save, the less importance undo has. (ie, if the
>system requires me to type in the filename each time, or navigate some
>gooey browser, I'd rather use undo) On the other hand, if undo is
>really good, I may save less often.
Save/restore could be improved upon --- there's really no reason I can
think of to even use a commandline for a task. Perhaps punching one
function key automatically saves the game, incrementing the filename
over previous saves; another function key restores the last game
saved; and a third function key calls up a more flexible dialog box.
>I find many games without undo to be very annoying though (and yes,
>that includes many the infocom games). It's just a matter of how much
>annoyance to put up with. However, for someone designing a NEW system
>to ask if they can design a system that will be annoying, well, that's
>just even more annoying :-)
I wasn't actually asking for permission. :-)
Perhaps I should have asked the question I'm really thinking about,
which is this: if a game offered some genuinely advanced
functionality, like substantially enhanced NPCs or something of that
sort, would losing undo-ability be a reasonable price to pay in those
special cases?
Doeadeer3
>From: ktyer...@aol.com (KTyers1951)
>Date: Fri, Jun 26, 1998 13:51 EDT
>Don't know what everyone else thinks, but personally I don't use UNDO even if
>it's there - I forget it's there half the time.....
Ditto, I didn't realize it was there. Probably because the old Infocom games
didn't have it.
It is only in recent weeks with all the discussion in raif about undo, that I
have actually started using it.
I LIKE IT! Now, if I want to, I can *let* my character die just to see what
happens, take a risk I might not otherwise.
I like having more options.
:-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
Andrew Plotkin
Eric O'Dell (eod...@pobox.com) wrote:
> The best way I can think of to handle undo is to maintain
> a linked list of actions that must be executed to backtrack to a
> previous state, e.g. a player command that changes the value of
> variable x from 52 to 67 creates a series of undo commands something
> like
>
> set addr x to 52
> [followed by many instructions to roll back daemons and fuses]
> decrement turn counter
>
> Which is no biggie. However, CAVE is going to generate actual
> executable code rather than bytecode for a virtual machine,
TADS uses this scheme. It's a *tremendous* pain in the source code, and
it has led to some long-standing and subtle bugs. The infamous
"delword" bug is caused by the undo information about word-lists not
being properly updated.
Presumably you're going to *also* need state-dumping code for every
possible piece of information. To implement save and restore, I mean. Are
you sure you don't want to just use that? You're proposing two complicated
and bug-prone subsystems, whose primary design goal is that they behave
identically.
> so this
> involves involves explicitly storing undo information if you add some
> special routine that won't fit into the API's scheme of supported
> types and data structures. I can see this being a real nightmare if
> the special routine you implemented involved some relatively complex
> AI subsystem.
That's another problem. The advantage of a programming langauge (over a
fixed library API) is largely negated if programmers have to write code
*and* save code *and* undo code. I think a lot of people would leave it
for last, and then things would slip through the cracks.
(Followups to RAIF only.)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Lelah Conrad
On Sat, 27 Jun 1998 01:44:39 GMT, Darin Johnson
<da...@usa.net.removethis> wrote:
>
>Sheesh. Sorry for going off the deep end, I like playing these
>games, but I don't like struggling with them.
Hear hear! Well stated!
Lelah
who jumps off deep end with Darin
Laurel Halbany
On Fri, 26 Jun 1998 18:26:59 GMT, okbl...@usa.net wrote:
>I'd like to see an entire genre of games arise that didn't require it.
>Something we discussed here before was the "real-life undo", where you can't
>actually go back in time and play the turn over again, but must use the same
>means you would use in real life to undo a bad action. (Death is
>problematic.)
Personally, I like UNDO for those times when I have a massive typo
blat, such as my one-year-old sneaking up on me and seizing the
keyboard.
Joe Mason
JID wrote:
>
> >Just wondering. I've never actually used UNDO; I find frequent saves
> >to be somewhat less jarring to the illusion of reality than UNDO, but
> >that may just be me.
>
> you can't help but come all the way out of the game and then go back in,
One note - just because only people who agree with this are posting
doesn't mean everybody (or even most people) prefer save to undo. I
like undo better, myself. And yes, I'd consider any system without undo
seriously crippled.
Joe
okbl...@usa.net
In article <359488fe.489664280@news>,
eod...@pobox.com wrote:
>
> Perhaps I should have asked the question I'm really thinking about,
> which is this: if a game offered some genuinely advanced
> functionality, like substantially enhanced NPCs or something of that
> sort, would losing undo-ability be a reasonable price to pay in those
> special cases?
>
Yes.
[ok]
okbl...@usa.net
In article <tvy1zsb...@cn1.connectnet.com>,
Darin Johnson <da...@usa.net.removethis> wrote:
>
> But no game *requires* undo. It's a player convenience - I rank
> it up there with command history and "g" aliased to "again".
>
Let's say it's not a boolean: Games that would be increasingly less tolerable
without UNDO require it to the degree that they become less effective as games
and fiction. Let's also lump UNDO in with SAVE/RESTORE (where SAVE/RESTORE
extends beyond the Nethack-style of "You get one save so that you can exit the
program and come back later, not so you can do stupid things.") and starting
the game over again because you didn't like the outcome (as opposed to just
wanting to re-read or re-play).
These all stem from the same approximate thing: The desire to use knowledge
gained from doing something that, within the context of the game, is
dangerous.
This should lead to the answer of why some authors hate it so much. If
possible, some writers would make it impossible for you to skip chapters in
their novels, or to peek at the end to see how everything turns out before
reading from the beginning.
Anyway, what I was postulating above was an ideal of "games that the user
never thinks of using undo anymore than he would in real life." :-) Lord
knows I've wished for UNDO on a few occasions--even a full-blown save and
restore.
You wouldn't necessarily always want a NO UNDO state. As someone else said, a
comedy could benefit greatly from UNDO. Although, I think there a better
answer might be "cartoon physics". :-)
But let's take a look at the possibility of a game that presents you with two
choices. One of those choices results in a character you've come to care
about dying. After you've made the choice, you may well have an overpowering
urge to use UNDO, but to allow it would be to defeat the purpose of having
you make the choice in the first place. (Presuming the situation was
well-thought out and the consequences known by the author.)
I know there are a lot of pro-UNDO sentiments here, for a variety of reasons,
but I think this would be a valid place where the author is justified in
disabling UNDO. (As someone else pointed out in an unrelated thread, it's
better if there are a variety of choices, including those the author hasn't
thought of; a situation with precisely two choices is going to seem contrived
and arbitrary if not well set up.)
> Why do authors hate undo so much? Why is there even a discussion
> about getting rid of it ? Yes, I know, because someone thought it
> would be had to implement, but I've heard plenty of people talk about
> eliminating it in situations where it is already implemented.
Well, to be honest, I don't know if the above scenario--a situation where the
IF was so moving as to create the same feeling of "wanting to undo" that one
has in life--is possible in any current implementation.
But say you had an implementation where things were meticulously tracked:
Part of the physics of the game involved not just the arrangement of
particles but also attitudes of NPCs which were subtly affected by actions,
where each turn taken by the user was followed a huge ripple effect
throughout the rest of the game universe, and it was (in fact) this ripple
that created the situation that the player wanted to undo. (phew!)
UNDO is still theoretically possible, but it becomes problematic.
SAVE/RESTORE can even be problematic, just due to space constraints.
> If players hate it, they don't have to use it. But if an author goes
> out of their way to remove it, it's insulting to me. It's like saying
> "I want to make your life hard", because that's exactly what happens.
I feel your pain. :-) I'm also sure that "author arrogance", as you put it,
is the main reason for undoing undo. :-) But Mr. O'Dell is designing a new
system, which he has since elaborated on, where undoing complex NPC
interaction is part of the puzzle.
> Yes, death is problematic. What do you think undo is for? Actions
> that inalterably change the game are problematic! If you new
> something might be dangerous or unalterable, one could save - but
> *usually* one doesn't know. One wouldn't expect that opening the
> jeweled egg messes you up, so one might not save the game beforehand.
Well, this is what I mean by "not requiring undo". No action should be
unexpectedly dangerous. Some actions should be unalterable, though not
arbitrarily so. (Someone was discussing the use of irony, and doing
something unalterable can give on more than their daily required dose of
irony.) You stop in the bar for a drink before going to carry a message to
Juliet, and when you get there, you find out she and Romeo are dead because
they didn't get your message. Isn't it ironic? UNDO?
> Yes, if you can design a game where I will never feel the need to
> use undo, then great, do it, and I will support you. But I've run
> across very very few games where I did not feel the need for an undo
> now and then. I've run across a few where even multiple undos were
> very helpful (because a single undo didn't fix things).
UNDO is a decidedly useful convention. We may not be able to get rid of it in
the near future. But I don't know if I would want someone trying to design a
good system worrying first about undo-ability.
> But *write* those games, don't remove undo instead! And after you've
> written such a game, you will have no need figure out convoluted
> schemes to disable undo, because in such a well designed game no
> player would use it anyway.
>
> Sheesh. Sorry for going off the deep end, I like playing these
> games, but I don't like struggling with them.
's alright. Your rant bears repeating.
Darin Johnson
eod...@pobox.com (Eric O'Dell) writes:
> I dunno what emacs does,
> besides acting as an object lesson in over-engineering.
To build emacs, you start with the basic compiled C code, then load in
all the extension lisp files. When done, you garbage collection and
compact memory, then dump the state of all memory to a new executable
file. Thus running that new emacs will have all the lisp extensions
automatically.
I mentioned that, because that approach would be a brute force method
of saving a game, if one couldn't figure out which variables needed
saving or not.
One method of doing undo, if you can do a save, is save to a region of
memory after each turn. It takes up extra space, is slow, but is
accurate. Which is why I said that if you can save, you can do
implement undo (just not efficiently).
> Perhaps I should have asked the question I'm really thinking about,
> which is this: if a game offered some genuinely advanced
> functionality, like substantially enhanced NPCs or something of that
> sort, would losing undo-ability be a reasonable price to pay in those
> special cases?
What if those abilities could be backported into a game system that
has undos? All C is going to give you is speed. If I wanted to do a
substantially enhanced NPC, I wouldn't start from a C/C++ base, I'd
use Lisp, Smalltalk, Java, or something advanced.
--
Darin Johnson
da...@usa.net.delete_me
okbl...@usa.net
CLARIFICATION:
In article <6n3q3d$ts$1...@nnrp1.dejanews.com>,
okbl...@usa.net wrote:
>
> Let's say it's not a boolean: Games that would be increasingly less tolerable
> without UNDO require it to the degree that they become less effective as
games
> and fiction.
Should have been "IF requires UNDO to the degree that it becomes less
effective as a game and fiction without it."
CORRECTION:
<<Someone was discussing the use of irony, and doing something unalterable can
give on more than their daily required dose of irony.)>>
Should have been "give ONE more than HIS daily required does of irony."
Isn't *that* ironic?
;-)
Trevor Barrie
>You wouldn't necessarily always want a NO UNDO state. As someone else said, a
>comedy could benefit greatly from UNDO. Although, I think there a better
>answer might be "cartoon physics". :-)
Speaking of cartoons, one could easily see Wile E. Coyote as an IF protagonist
who uses undo a lot.:) (Note that we never actually see him recover on screen.)
Jonadab
> JID wrote:
> >
> > >Just wondering. I've never actually used UNDO; I find frequent saves
> > >to be somewhat less jarring to the illusion of reality than UNDO, but
> > >that may just be me.
> >
> > Nicely put. That's exactly how I feel. I think because with
save/restore,
> > you can't help but come all the way out of the game and then go back
in,
Joe Mason wrote
>
> One note - just because only people who agree with this are posting
> doesn't mean everybody (or even most people) prefer save to undo. I
> like undo better, myself. And yes, I'd consider any system without undo
> seriously crippled.
>
> Joe
>
On the other hand, undo will never serve as a substitute for save and
restore. Many players prefer to save the game, go do something else, and
come back the next day -- this is the *only* way *I* play any game longer
than a chicken comp entry. So if there's no save feature, that's a very
serious crippling. Lack of undo would be a pain, particularly if there
were easy ways to die or render the game unsolvable with little warning,
but lack of save would, IMO, be at least an order of magnitude worse.
(Everything I write is my opinion, or I wouldn't write it.)
----------------
One of the many uses for peanut butter:
289. Polish your sandals with it.
(Need more uses? see http://members.kconline.com/kerr/pb.htm)
Send replies to username@isp, where username is jonadab
and isp is bright.net
The zerospam.com address works, but you get an ugly confirmation.
Visit Jonadab's Domain: http://www.bright.net/~jonadab/
Darin Johnson
okbl...@usa.net writes:
> This should lead to the answer of why some authors hate it so much. If
> possible, some writers would make it impossible for you to skip chapters in
> their novels, or to peek at the end to see how everything turns out before
> reading from the beginning.
I've never seen a book that disallowed going back a few pages either.
I do that constantly while reading.
There's an idea going around, that seems popular here, and with web
page authors, and some others. It's the idea that the author should
have full and complete control over how the reader/viewer uses the
work. That is, read my work exactly how I want you to, or don't read
it at all. View the web page at my chosen resolution and with my
fonts and with nonportable html, or don't view it at all. This idea
never seems to come from people I consider noteworthy writers.
I find this a disturbing idea. If the writing is good enough, such
author control isn't necessary. If the writing isn't good though,
then such control is just pretentious.
> But let's take a look at the possibility of a game that presents you with two
> choices. One of those choices results in a character you've come to care
> about dying. After you've made the choice, you may well have an overpowering
> urge to use UNDO, but to allow it would be to defeat the purpose of having
> you make the choice in the first place. (Presuming the situation was
> well-thought out and the consequences known by the author.)
So, to see the alternate choice, you would require the player (also
known as "reader" to some) to replay a significant portion of the game
to reach that point? I presume that if you disallow undo, you'll
disallow save as well? Sorry, but either the game is compelling
enough that I won't want to do the undo/restore, or else I'll just box
the game up and let it gather dust.
--
Darin Johnson
da...@usa.net.delete_me
Eric O'Dell
On Sat, 27 Jun 1998 21:25:21 GMT, Darin Johnson
<da...@usa.net.removethis> wrote:
>What if those abilities could be backported into a game system that
>has undos? All C is going to give you is speed. If I wanted to do a
>substantially enhanced NPC, I wouldn't start from a C/C++ base, I'd
>use Lisp, Smalltalk, Java, or something advanced.
Actually, the speed provided by C is only one consideration that bore
into the decision. The others, in no particular order, were:
1. C is probably more widely known and supported than any other
non-proprietary language. Good free and commercial C compilers are
available for most PC operating systems, and I presume the Mac as
well. A vast body of freely available code already exists.
2. Most popular operating systems provide a C API, making it easier to
implement system-specific extensions, like multimedia elements, which
is one of the primary goals of the system.
3. Java is a proprietary language owned by a company whose chief
objection to Microsoft's business practices is that they can't get
away with doing the same things.
4. I don't know Lisp or Smalltalk.
Eric O'Dell
On Sat, 27 Jun 1998 13:45:41 GMT, erky...@netcom.com (Andrew Plotkin)
wrote:
>That's another problem. The advantage of a programming langauge (over a
>fixed library API) is largely negated if programmers have to write code
>*and* save code *and* undo code. I think a lot of people would leave it
>for last, and then things would slip through the cracks.
You have a point there. I think I see how it could be done without
being a serious pain for the user...
Eric O'Dell
On Sat, 27 Jun 1998 21:13:10 GMT, okbl...@usa.net wrote:
>> Perhaps I should have asked the question I'm really thinking about,
>> which is this: if a game offered some genuinely advanced
>> functionality, like substantially enhanced NPCs or something of that
>> sort, would losing undo-ability be a reasonable price to pay in those
>> special cases?
>
I guess the next important question is, how many levels of undo are
enough? I don't guess it would be too difficult to code the system so
that the user could specify a certain amount of memory to use for
storing undo information.
Darin Johnson
eod...@pobox.com (Eric O'Dell) writes:
> I guess the next important question is, how many levels of undo are
> enough? I don't guess it would be too difficult to code the system so
> that the user could specify a certain amount of memory to use for
> storing undo information.
One is enough, but... If you implement it using "deltas", then just
allocate a fixed amount of space, then allow how ever many undo's can
fit in it. Some undo's take up a lot of space, but most are tiny.
(ie, use a circular array or buffer, not a linked list)
--
Darin Johnson
da...@usa.net.delete_me
Darin Johnson
eod...@pobox.com (Eric O'Dell) writes:
> 3. Java is a proprietary language owned by a company whose chief
> objection to Microsoft's business practices is that they can't get
> away with doing the same things.
Is this troll bait? Java is proprietary, but you can use it for free,
and write your own for free. All you can't do is change it to be
nonstandard and still call it Java. That's the only thing Sun has
against MS wrt Java.
> 4. I don't know Lisp or Smalltalk.
You should. Add it to your list of things to do. These are classics
(yet still currently applicable). It will make you a better
programmer, even if you never use them.
--
Darin Johnson
da...@usa.net.delete_me
Matt Kimball
In rec.arts.int-fiction Darin Johnson <da...@usa.net.removethis> wrote:
: eod...@pobox.com (Eric O'Dell) writes:
:> 3. Java is a proprietary language owned by a company whose chief
:> objection to Microsoft's business practices is that they can't get
:> away with doing the same things.
: Is this troll bait? Java is proprietary, but you can use it for free,
: and write your own for free. All you can't do is change it to be
: nonstandard and still call it Java. That's the only thing Sun has
: against MS wrt Java.
There isn't a good free[1] implementation of Java available yet.
There are good free[2] C compilers available. And it is an ANSI and
ISO standard, not owned by any company or dominated by one
implementation. This is one reason to choose C over Java for a
project you want to be cross platform. (Which is ironic considering
how Sun is marketing Java). I don't know if this is what Eric was
suggesting, but I consider it a valid issue.
Also, Sun doesn't release their JDK with a free[3] license now, so
what makes you think that if Java suddenly became the standard binary
format for shrinkwrapped software, Sun wouldn't try to leverage their
control over the Java standard in order to eliminate competition?
Maybe they would only release new versions of the JDK for Solaris and
change their licensing so that outside ports to operating systems with
smaller user bases are no longer allowed, in order to encourage people
to "upgrade" to Solaris. It isn't that hard for me to believe, but
maybe I am just a paranoid Linux user.
No thanks, I'll choose technology with good open-source
implementations already available, especially when it's on my own
time.
[1] By free, I mean source code publically available without NDA, with
a license that allows the distribution of the source code and binaries of
derivative works. The license on Sun's JDK isn't free enough for me, and
projects such as Kaffe and Japhar haven't matured to the point that they
are useful replacements for Sun's JDK. With Sun adding new stuff to the
language at their current rate, it looks like it might be a while before
they reach that point.
[2] Same defininition of free as above. gcc and others are available.
[3] Again, source code public and allows for distribution of
derivative works.
--
Matt Kimball
mkim...@xmission.com
Weird Beard
Matt Kimball wrote in message <6n69q0$7gb$1...@news.xmission.com>...
>[1] By free, I mean source code publically available without NDA, with
>a license that allows the distribution of the source code and binaries of
>derivative works
Excuse me, but what have you done to *deserve* the right to create a
derivative work? Have you spent hours and hours creating a marketable
product? These people depend on the software they create for their bread and
butter. Why should they *help* you compete with them?
Andrew Plotkin
Weird Beard (WEIRD...@prodigy.net) wrote:
> Matt Kimball wrote in message <6n69q0$7gb$1...@news.xmission.com>...
> >[1] By free, I mean source code publically available without NDA, with
> >a license that allows the distribution of the source code and binaries of
> >derivative works
> Excuse me, but what have you done to *deserve* the right to create a
> derivative work?
This has taken a sudden bizarre turn. I think I'm out of this thread.
Matt Kimball
In rec.arts.int-fiction Weird Beard <WEIRD...@prodigy.net> wrote:
: Matt Kimball wrote in message <6n69q0$7gb$1...@news.xmission.com>...
:>[1] By free, I mean source code publically available without NDA, with
:>a license that allows the distribution of the source code and binaries of
:>derivative works
: Excuse me, but what have you done to *deserve* the right to create a
: derivative work?
[ Note, I added gnu.misc.discuss to the newsgroups line and set
follow-ups there. Let's try to keep r.?.i-f from straying further
off topic. ]
Nothing. It isn't a right. It's a preference. I'm not demanding
anyone release their software under terms like this. I simply choose
products that are free in that sense over those products that aren't.
Why? Because software distributed under terms like those (permissive
of derivative works, etc) end up being more reliable[1] and don't
restrict me when I want to extend or fix them. Products with those
types of licenses are much more helpful to me in the long run.
Of course you are free to choose differently.
: Have you spent hours and hours creating a marketable product?
Yes, I currently work as a programmer for a company which produces
proprietary software products. This doesn't change my preferences
when I choose to which software to use.
: These people depend on the software they create for their bread and
: butter. Why should they *help* you compete with them?
Because they want my business? I am more than happy to purchase
software if the software is non-proprietary. And if there is a
non-proprietary solution, I will choose it over the proprietary one.
[1] In my experience. YMMV.
--
Matt Kimball
mkim...@xmission.com
Darin Johnson
Matt Kimball <mkim...@xmission.com> writes:
> There isn't a good free[1] implementation of Java available yet.
> There are good free[2] C compilers available. And it is an ANSI and
> ISO standard, not owned by any company or dominated by one
> implementation. This is one reason to choose C over Java for a
> project you want to be cross platform. (Which is ironic considering
> how Sun is marketing Java). I don't know if this is what Eric was
> suggesting, but I consider it a valid issue.
Is Sun marketting Java as a final product, or are they marketting it
as a road towards portability?
I do agree they made a huge blunder. Anytime you release an initial
product that is not perfect, a huge majority of people who try it and
dislike it will *never* give it a second try, ever. It should have
been more stable, if only so that in ten years, you won't hear people
saying "yeah, I tried Java 1.0, but it was buggy".
Standards aren't that strong to ensure portability. There are current
latest release compilers from some vendors that aren't 100% ISO C
compliant. I expect Sun to release Java to a standards committee
somewhere along the line. It's stupid to do so now, because there is
currently a huge company that is well known for subverting standards
out there, and Java needs to be better established before letting it
swim with the sharks.
> Also, Sun doesn't release their JDK with a free[3] license now, so
> what makes you think that if Java suddenly became the standard binary
> format for shrinkwrapped software, Sun wouldn't try to leverage their
> control over the Java standard in order to eliminate competition?
What makes you think they will? Catch-22. If you make a free license
that allows derivatives, Microsoft would completely destroy any hope
of Java portability. They are trying to do this NOW. On the other
hand, they try to prevent derivatives, and some people think Sun is
trying to be proprietary. Microsoft even has C derivatives
("windows.h" requires a non-standard C compiler just to parse it).
But Sun has a long and well known history of providing open standards.
Microsoft has a long and well known history of subverting standards.
Thus, I trust Sun to make Java open in the future, since this is how
Sun usually works. I trust Microsoft to try and screw the industry,
since this is how Microsoft usually works.
> It isn't that hard for me to believe, but
> maybe I am just a paranoid Linux user.
Linux uses many open standards initially created by Sun.
> [3] Again, source code public and allows for distribution of
> derivative works.
But would you allow people to distrubute derivatives of Java and still
call it Java? That's the catch. How do you prevent having
Windows-only Java programs, Linux only Java programs, Mac only Java
programs, and so forth?
You can create derivatives of GCC, but you can't create derivatives of
the C language and still call it "C". Sun allows you to modify the
JDK, else there'd be no Linux JDK. They don't allow you to use it to
create a new language and try to put the "Java" name on it though.
--
Darin Johnson
da...@usa.net.delete_me
Eric O'Dell
On Sun, 28 Jun 1998 19:03:03 GMT, Darin Johnson
<da...@usa.net.removethis> wrote:
>> 3. Java is a proprietary language owned by a company whose chief
>> objection to Microsoft's business practices is that they can't get
>> away with doing the same things.
>
>Is this troll bait? Java is proprietary, but you can use it for free,
>and write your own for free. All you can't do is change it to be
>nonstandard and still call it Java. That's the only thing Sun has
>against MS wrt Java.
No, it was mostly an attempt to avoid spawning a pointless thread
regarding my opinion that Java is a cheap marketing ploy thinly
disguised as a poorly designed language that has yet to achieve its
own design goals, much less prove itself a long-term workable solution
to anything in particular. Which is a strong opinion that is not
likely to be provable one way or the other, although it might make for
a suitably tedious flamewar in some other newsgroup.
But yes, I do believe that, provided Java ever achieves broad
commercial acceptance, Sun will leverage its control over the language
to the detriment of everyone else.
>> 4. I don't know Lisp or Smalltalk.
>
>You should. Add it to your list of things to do. These are classics
>(yet still currently applicable). It will make you a better
>programmer, even if you never use them.
This, on the other hand, is probably true, and I will add them to my
list of things to do.
Matt Kimball
In rec.arts.int-fiction Darin Johnson <da...@usa.net.removethis> wrote:
: Matt Kimball <mkim...@xmission.com> writes:
:> It isn't that hard for me to believe, but
:> maybe I am just a paranoid Linux user.
: Linux uses many open standards initially created by Sun.
Agreed. And I am happy to use them now that there is a libre
implementation of those standards.
:> [3] Again, source code public and allows for distribution of
:> derivative works.
: But would you allow people to distrubute derivatives of Java and still
: call it Java? That's the catch. How do you prevent having
: Windows-only Java programs, Linux only Java programs, Mac only Java
: programs, and so forth?
Well, here is the spirit of a license I would be happy with:
Here is the source code to the Sun JDK. You can download it from
ftp.sun.com. You can modify the code and distribute modified code,
but if the resulting code doesn't pass our Java test suite, you can't
call it Java, you need to call it something else.
Would Microsoft try to take advantage of such a license? Probably.
But I think it would protect Sun from Microsoft just as much as the
current license protects them from Microsoft reimplementing Java.
--
Matt Kimball
mkim...@xmission.com
Eric O'Dell
>>[1] By free, I mean source code publically available without NDA, with
>>a license that allows the distribution of the source code and binaries of
>>derivative works
>
>Excuse me, but what have you done to *deserve* the right to create a
>derivative work? Have you spent hours and hours creating a marketable
>product? These people depend on the software they create for their bread and
>butter. Why should they *help* you compete with them?
That settles it. I will put forth whatever effort is necessary to code
an effective UNDO feature in CAVE. Now if I could just code one into
popular newsreaders so that if a user stumbles into a flamewar over
language characteristics and market theory while ostensibly
considering runtime IF system features, he can restore the previous
thread state and move on.
L. Ross Raszewski
In article <35980231.651788319@news>,
eod...@pobox.com wrote:
>
> That settles it. I will put forth whatever effort is necessary to code
> an effective UNDO feature in CAVE. Now if I could just code one into
> popular newsreaders so that if a user stumbles into a flamewar over
> language characteristics and market theory while ostensibly
> considering runtime IF system features, he can restore the previous
> thread state and move on.
>
> --Eric
THUNDEROUS Applause.
Michael Straight
On Sat, 27 Jun 1998 okbl...@usa.net wrote:
> But let's take a look at the possibility of a game that presents you with two
> choices. One of those choices results in a character you've come to care
> about dying. After you've made the choice, you may well have an overpowering
> urge to use UNDO, but to allow it would be to defeat the purpose of having
> you make the choice in the first place. (Presuming the situation was
> well-thought out and the consequences known by the author.)
Are you thinking this through? Say you've written a game where it is
possible to die in the first third of the game. Are you really content
that some players would never see the last two-thirds of your hard work
just for the sake of having this kind of integrity? Wouldn't starting
completely over and replaying the game and making the other choice be just
as bad as using UNDO?
UNDO allows players to see _more_ of your work.
SMTIRCAHIAGEHLT
okbl...@usa.net
In article <tvy90mi...@cn1.connectnet.com>,
Darin Johnson <da...@usa.net.removethis> wrote:
>
> I've never seen a book that disallowed going back a few pages either.
> I do that constantly while reading.
>
Some writers would probably want to disallow this as well.
> There's an idea going around, that seems popular here, and with web
> page authors, and some others. It's the idea that the author should
> have full and complete control over how the reader/viewer uses the
> work. That is, read my work exactly how I want you to, or don't read
> it at all. View the web page at my chosen resolution and with my
> fonts and with nonportable html, or don't view it at all. This idea
> never seems to come from people I consider noteworthy writers.
>
> I find this a disturbing idea. If the writing is good enough, such
> author control isn't necessary. If the writing isn't good though,
> then such control is just pretentious.
Well, wouldn't any attempt to assert a change seem pretentious if not
successful? Pretentiousness can arise from a sort of failed genius, can't it?
(I mean, if it's earnestly meant. Otherwise it's more like camp.) Not to say
that all pretentiousness falls into this category.
In the case of the world-wide web, there are few pages that I consider worthy
of changing my mode of access for. But I wouldn't deny the author the chance
to control the way his information was presented.
In an extreme case, you might sit down with, say, _Moby Dick_, only the copy
is done on cheap paper, low contrast ink, and small print, and you might walk
away with a bad feeling about the book based primarily on the presentation,
and not, say, on the unending descriptions of whaling. The author's
intentions have been perverted by bad presentation.
As someone who uses Netscape 2.02 and WebExplorer regularly, I run into a lot
of barf on the web. I can understand someone not wanting to show me his
page.
> So, to see the alternate choice, you would require the player (also
> known as "reader" to some) to replay a significant portion of the game
> to reach that point? I presume that if you disallow undo, you'll
> disallow save as well? Sorry, but either the game is compelling
> enough that I won't want to do the undo/restore, or else I'll just box
> the game up and let it gather dust.
If you don't want to do the UNDO, how will you know if it's not there? :-)
Obviously the placement of such sections would be part of the art as well.
(I think a lot of people SAVE as a nervous habit.) I don't know what "a
significant portion of the game" means, though, really. Literally, it would
be true: whether one move or a thousand moves, the point of suspending the
save or undo feature would be to give the author a chance to react to the
knowledge that you're replaying an area.
I think some of the reaction from people here is based on the idea that
someone, somewhere will abuse this by creating a story that requires you to
replay a thousand moves based on some random outcome. Well, probably. :-)
But that wouldn't be the point of the feature, any more than the point of the
RANDOM feature is to allow authors to torture players by making them guess at
things.
What I'm getting at is that, fundamentally, author control is not a bad thing.
It is abused, and *that* is bad. My example of where an author might disable
UNDO might not be a very good one, but my own limitations on communicating a
situation where it the ability valuable doesn't mean that such situations
wouldn't exist and be powerful in the right hands.
okbl...@usa.net
In article <6n3usr$7e$1...@drollsden.ibm.net>,
tba...@ibm.net (Trevor Barrie) wrote:
>
> Speaking of cartoons, one could easily see Wile E. Coyote as an IF protagonist
> who uses undo a lot.:) (Note that we never actually see him recover on
screen.)
Actually, complete and perfect recovery from all conditions (short of cartoon
death which is a special topic unto itself) is a normal part of cartoon
biology.
Cartoon biology, cartoon physics and cartoon chemistry were my majors in
college. :-)
Darin Johnson
Matt Kimball <mkim...@xmission.com> writes:
> Well, here is the spirit of a license I would be happy with:
>
> Here is the source code to the Sun JDK. You can download it from
> ftp.sun.com. You can modify the code and distribute modified code,
> but if the resulting code doesn't pass our Java test suite, you can't
> call it Java, you need to call it something else.
That's only the spirit of a license. Put any company's lawyers to
translating it, and you end up with pages worth if unreadable
mess :-)
--
Darin Johnson
da...@usa.net.delete_me
okbl...@usa.net
In article <Pine.A41.3.95L.98062...@login1.isis.unc.edu>,
Michael Straight <stra...@email.unc.edu> wrote:
>
> Are you thinking this through? Say you've written a game where it is
> possible to die in the first third of the game. Are you really content
> that some players would never see the last two-thirds of your hard work
> just for the sake of having this kind of integrity? Wouldn't starting
> completely over and replaying the game and making the other choice be just
> as bad as using UNDO?
>
> UNDO allows players to see _more_ of your work.
>
This presumes several things: That you would disable UNDO in a game where it
was possible to die a third of the way through; that death would be a
permanent state (and I've had games where death was as inevitable as taxes
but in no way meant the end of the game); and that there is no circumstance
where death in the first third of the game wouldn't be just exactly what you
were looking for, in some cases.
Maybe I'm out on a limb here, but it seems to me that greater interactivity is
going to mean that people have different experiences playing the game. That
might mean that a very cautious person plays the game for years while a more
reckless one plays it for a day, perhaps each reaching a different end of the
game.
I'm just suggesting that the possibility is there. I believe more work has
to be done in the interactivity department. I liked the idea suggested
earlier of a game without any form of UNDO, where to undo something you had
to do what you would in real-life. I realize we're talking about a departure
here.
Stu042
>
>Cartoon biology, cartoon physics and cartoon chemistry were my majors in
>college. :-)
At some Mickey Mouse college no doubt... :P
~~stu
Giles Boutel
Michael Straight <stra...@email.unc.edu> wrote in article
<Pine.A41.3.95L.98062...@login1.isis.unc.edu>...
>
> UNDO allows players to see _more_ of your work.
>
I guess it comes down to the different ways people play the games. I,
personally, start the game and go exploring, and hopefully figure out a few
things to do without worrying about turns passed etc. I'll generally then
restart and do the things I know about and save at that point. Then I
continue exploring, experimenting, and generally mucking about, going back
to the first save upon dying or completing a few more puzzles. I then
return to the first save and use the new knowledge to quickly get to a
second save point, whereupon I continue exploring.
I think this pattern of behaviour was largely influenced by move-counting
games like enchanter (with its food requirement), Planetfall, etc. It's a
useful practice in that you end up with any number of saves at various
points, so you can go back and check that you haven't missed anything in
earlier stages. It also gives you the opportunity to 'live dangerously' and
see parts of the game that you might not were you being overly cautious.
Modern games seem to do away with time limits (_Time_ being an obvious
exception, not to mention the later parts of _Spider and Web_) but old
habits die hard - especially since I use Jzip as an interpreter 90% of the
time, which only has single move undo and only gets used occasionally (by
me) in sudden death situations.
-Giles
okbl...@usa.net
In article <199806292048...@ladder01.news.aol.com>,
stu...@aol.com (Stu042) wrote:
>
> >Cartoon biology, cartoon physics and cartoon chemistry were my majors in
> >college. :-)
>
> At some Mickey Mouse college no doubt... :P
>
Actually, good ol' MMU is only a short drive from here but, alas, I did not
attend.
Paul O'Brian
On Mon, 29 Jun 1998, Michael Straight wrote:
> On Sat, 27 Jun 1998 okbl...@usa.net wrote:
> > But let's take a look at the possibility of a game that presents you with two
> > choices. One of those choices results in a character you've come to care
> > about dying. After you've made the choice, you may well have an overpowering
> > urge to use UNDO, but to allow it would be to defeat the purpose of having
> > you make the choice in the first place. (Presuming the situation was
> > well-thought out and the consequences known by the author.)
>
> possible to die in the first third of the game. Are you really content
> that some players would never see the last two-thirds of your hard work
> just for the sake of having this kind of integrity? Wouldn't starting
> completely over and replaying the game and making the other choice be just
> as bad as using UNDO?
>
Allow me to suggest that in both of those situations, if the game's
writing was good enough, I would play both branches just to see what
happened anyway, and would greatly appreciate the convenience of a SAVE
or UNDO which allowed me to do so without starting from scratch. To
me, this ability to explore different directions & outcomes is part of the
pleasure of interactive fiction, as opposed to "static" fiction.
Paul O'Brian
obr...@colorado.edu
http://ucsu.colorado.edu/~obrian
okbl...@usa.net
In article <Pine.GSO.3.96.980702...@ucsu.Colorado.EDU>,
Paul O'Brian <obr...@ucsu.Colorado.EDU> wrote:
>
> Allow me to suggest that in both of those situations, if the game's
> writing was good enough, I would play both branches just to see what
> happened anyway, and would greatly appreciate the convenience of a SAVE
> or UNDO which allowed me to do so without starting from scratch. To
> me, this ability to explore different directions & outcomes is part of the
> pleasure of interactive fiction, as opposed to "static" fiction.
>
I concede the reasonableness of the sentiment. I only maintain that an artist
needs to have the right to be unreasonable from time-to-time. Anyone remember
who said "In art, you have to shoot your grandmother"?
Of course, now I'm imagining an entire generation of Andy Kaufman-esque IF
programmers whose entire body of work exists to incite people to violence....
Kjetil Aavik
> On the other hand, undo will never serve as a substitute for save and
> restore. Many players prefer to save the game, go do something else,
> and come back the next day
Whaddayamean, "do something else"? Anyways, undo is nice. Really.
-Kjetil