[Inform] Turn off "undo"
Joe Mason
In Inform, is there any way I can turn off the "undo" feature in my
game?
Joe
Andrew Plotkin
Joe Mason (joe....@tabb.com) wrote:
> In Inform, is there any way I can turn off the "undo" feature in my
> game?
Go into the Parser library.
Look at the Keyboard() routine.
Find the place where it calls @restore_undo i;
Start editing. :-)
(The clean way would be to Replace Keyboard, and copy the whole Keyboard
function into your source file, and edit the copy. Well, cleanish.)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Julian Arnold
In article <66.578...@tabb.com>, Joe Mason
<URL:mailto:joe....@tabb.com> wrote:
>
> In Inform, is there any way I can turn off the "undo" feature in my
> game?
*UNTESTED*
You could try setting undo_flag to 1 in Initialise(). This gives a
slightly misleading message, but that's easily altered through
LibraryMessages.
Jools
--
mathew
In article <66.578...@tabb.com>, Joe Mason <joe....@tabb.com> wrote:
>In Inform, is there any way I can turn off the "undo" feature in my
>game?
You're sponsored by the makers of disk space for game saves, perhaps?
If I found a game which had no undo *and* wouldn't let me save, it'd
go straight in the bin.
mathew
--
me...@pobox.com home page with *content* at http://www.pobox.com/%7Emeta/
Help prevent economic bias on the net - support the Open Text Boycott
See http://www.pobox.com/%7Emeta/rs/ot/ for details
Andrew Plotkin
aul...@koala.scott.net wrote:
> >> In Inform, is there any way I can turn off the "undo" feature in my
> >> game?
>
> has been) implemented in Z-code interpreters, anyway. I'll always be able
> to Alt-U in Frotz, no matter what your code says.
This is a flaw in Frotz, as far as I'm concerned. What if I want to write
a puzzle like the 12-cubes one in Spellbreaker? Should I just add a note
saying "This game does not work correctly in Frotz. Use a different
interpreter."?
What if I just want to add cute comments about "undo", a la Floyd's cute
comments about "save" and "restore"?
(Yes, I'm being sarcastic. But I do think that such interpreters should
make it clear that a this undo feature is a *cheat* feature. It's like a
interpreter feature to examine or set object attributes. I don't object to
writing interpreters that do this, but their users should know that using
the cheat keys may screw up game play.)
Julian Arnold
In article <ant28115...@arnod.demon.co.uk>, Julian Arnold
> >
> > In Inform, is there any way I can turn off the "undo" feature in my
> > game?
>
>
> You could try setting undo_flag to 1 in Initialise(). This gives a
> slightly misleading message, but that's easily altered through
> LibraryMessages.
*TESTED*
Doesn't work. :( Go get Keyboard() out of `parser.h' and rip out the
undo bits.
Jools
--
Carl Edman
Andrew Plotkin wrote:
> aul...@koala.scott.net wrote:
> > >> In Inform, is there any way I can turn off the "undo" feature in my
> > >> game?
> >
> > has been) implemented in Z-code interpreters, anyway. I'll always be able
> > to Alt-U in Frotz, no matter what your code says.
>
> This is a flaw in Frotz, as far as I'm concerned. What if I want to write
> a puzzle like the 12-cubes one in Spellbreaker? Should I just add a note
> saying "This game does not work correctly in Frotz. Use a different
> interpreter."?
No, you should implement the 12 cube puzzle properly. Neither load,
save nor undo will spoil it then. Let me explain:
For those who've never played Spellbreaker, the aim of this puzzle is to
identify the genuine, heavier cube among twelve lighter fakes using a
balance. The problem is that you only have time for three weighings.
Implementation 1: Pick the number of the genuine cube at random at
startup time. Disallow load, save, undo in the room.
The fastest way for any reasonably fast typist to solve this
implementation is just to save before entering the room, grab any cube
and try to use it. If it is the wrong cube, just reload and try the
next one.
Implementation 2: As 1, but reassign the number of the genuine cube
randomly every time.
No dice. Picking a cube at random will still work. Even if you now
need 12 rather than 6 reloads on average to solve the puzzle, this is
still faster for the average typist.
Implementation 3: As 2, but now I require the player to prove that his
cube is genuine by weighing it against a fake cube. Otherwise it will
be treated as fake, even if it was genuine.
Still wrong. I can pick a random pair of cubes and weigh them before
leaving the room. This way will only require 6 loads on average.
Implementation 4: Keep a twelve element array which indicates if the
corresponding cube could be genuine. Initialize this array to true.
Whenever the player performs a weighing the cubes fall into three sets
Left, Right and Outside. In the trivial case when the number of cubes
in the Left and Right sets aren't equal, just tilt to the larger set.
If the number of cubes are equal, tilt to the left with the probability
Number_of_possibly_genuine_cubes_in_Left_set/Number_of_possibly_genuine_cubes_overall.
If the balance tilts left, mark all the cubes in the Right and Outside
sets as fake. The procedure for the Right and Outside sets is the
equivalent. If you try to use a cube, it will be treated as a fake
unless you proved all other cubes to be fakes. Leave Save, Load and
Undo alone.
In every observable way the effect is the same as if the correct cube
had been predetermined. The only difference is that if you undo, all
the information you gained in the undone move also becomes invalid, so
undoing doesn't help you any longer. The problem with this
implementation is that by randomly picking pairs of cubes, you still
will get lucky pretty soon.
Implementation 5: As 4, but always tilt towards the side with the
largest number of possibly genuine cubes (if the Outside set has the
largest number, stay level). If there is a tie pick randomly.
This still looks to the player as if the genuine cube was
predetermined. The only difference is that the player always has the
worst of luck. That requires him to use the optimal algorithm and hence
solve the puzzle in the intended way, by thinking. This the Right
Implementation.
Please forgive my verbosity on this subject, but I've thought about it
and believe that a similar solution can be applied to all puzzles which
would be "spoiled" by undo. The basic idea is to keep all information
which is unknowable to the player, undetermined by the interpreter.
> What if I just want to add cute comments about "undo", a la Floyd's cute
> comments about "save" and "restore"?
Add them to the undo command. If there is a properly functioning
command, people won't use the frotz undo. If for no other reason,
because it tends to mess up the status line.
> (Yes, I'm being sarcastic. But I do think that such interpreters should
> make it clear that a this undo feature is a *cheat* feature. It's like a
> interpreter feature to examine or set object attributes. I don't object to
> writing interpreters that do this, but their users should know that using
> the cheat keys may screw up game play.)
Undo doesn't do anything which Load and Save don't do. If loading and
saving isn't cheating, neither is undo. Of course a case can be made
that they are. But then restarting the game in any way is as well.
Carl Edman
aul...@koala.scott.net
In article <erkyrathD...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>Joe Mason (joe....@tabb.com) wrote:
>> In Inform, is there any way I can turn off the "undo" feature in my
>> game?
>
You might not want to bother with this, because the feature can be (and
has been) implemented in Z-code interpreters, anyway. I'll always be able
to Alt-U in Frotz, no matter what your code says.
That is all,
Joe
Dan Shiovitz
In article <32265C88...@lynx.ps.uci.edu>,
Carl Edman <ced...@lynx.ps.uci.edu> wrote:
>Andrew Plotkin wrote:
>> aul...@koala.scott.net wrote:
>> > >> In Inform, is there any way I can turn off the "undo" feature in my
>> > >> game?
>> >
>> > You might not want to bother with this, because the feature can be (and
>> > has been) implemented in Z-code interpreters, anyway. I'll always be able
>> > to Alt-U in Frotz, no matter what your code says.
>>
>> This is a flaw in Frotz, as far as I'm concerned. What if I want to write
>> a puzzle like the 12-cubes one in Spellbreaker? Should I just add a note
>> saying "This game does not work correctly in Frotz. Use a different
>> interpreter."?
[spellbreaker puzzle deleted]
>Please forgive my verbosity on this subject, but I've thought about it
>and believe that a similar solution can be applied to all puzzles which
>would be "spoiled" by undo. The basic idea is to keep all information
>which is unknowable to the player, undetermined by the interpreter.
What if the information is potentially knowable, but currently unknown?
For instance (Curses spoiler)
To defuse the bomb, you need to pull the wires out in the right order.
To figure out the right order, you need to look at the scarf. What if
the player fails to look at the scarf, but uses undo to try all
possibilities and solves it that way?
>> What if I just want to add cute comments about "undo", a la Floyd's cute
>> comments about "save" and "restore"?
>
>Add them to the undo command. If there is a properly functioning
>command, people won't use the frotz undo. If for no other reason,
>because it tends to mess up the status line.
This is probably a point worth making. I think the single-turn undo is
an annoying enough feature of Inform that it should be taken out. I don't
know much about it, but I had the idea it was an arbitrary limit, just like
the number of objects and properties and so on.
>> (Yes, I'm being sarcastic. But I do think that such interpreters should
>> make it clear that a this undo feature is a *cheat* feature. It's like a
>> interpreter feature to examine or set object attributes. I don't object to
>> writing interpreters that do this, but their users should know that using
>> the cheat keys may screw up game play.)
>
>Undo doesn't do anything which Load and Save don't do. If loading and
>saving isn't cheating, neither is undo. Of course a case can be made
>that they are. But then restarting the game in any way is as well.
I'm pretty sure he was only speaking about the undo which Frotz does,
overriding the author's control over the game. I know if I was programming
in Inform, I'd be annoyed by it. (Of course, since I only play, I love it.
But I'd rather just have the language handle it better.)
> Carl Edman
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more sensible
people ... remember to speak up for freedom because no one else will do it
for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
Bruce Stephens
>>>>> "Dan" == Dan Shiovitz <scy...@u.washington.edu> writes:
> This is probably a point worth making. I think the single-turn undo
> is an annoying enough feature of Inform that it should be taken out.
> I don't know much about it, but I had the idea it was an arbitrary
> limit, just like the number of objects and properties and so on.
Inform doesn't provide undo: that's done by the interpreter, which
could certainly provide multiple-level undo if it wanted to. I
suspect interpreters didn't, simply because of memory limitations, but
with the small save files now used (O(2--5k)) that looks a bit silly.
Presumably we'll see more and more interpreters supporting
multiple-level undo. But it's nothing to do with Inform (although
perhaps a mechanism could be added to allow Inform to control the
feature, so you could say "undo 3" to undo three turns or something).
--
Bruce Stephens | email: B.Ste...@math.ruu.nl
Utrecht University | telephone: +31 30 2534630
Department of Mathematics | telefax: +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands |
Julian Arnold
>
> aul...@koala.scott.net wrote:
> > You might not want to bother with this, because the feature can be (and
> > has been) implemented in Z-code interpreters, anyway. I'll always be able
> > to Alt-U in Frotz, no matter what your code says.
>
> This is a flaw in Frotz, as far as I'm concerned. What if I want to write
> a puzzle like the 12-cubes one in Spellbreaker? Should I just add a note
> saying "This game does not work correctly in Frotz. Use a different
> interpreter."?
I agree with Andrew.
> It's like an
> interpreter feature to examine or set object attributes.
Can interpreters do this? Makes `AttrTest.h' somewhat redundant then. :(
Jools
--
Julian Arnold
In article <wwawwyh...@cantecler.math.ruu.nl>, Bruce Stephens
<URL:mailto:step...@math.ruu.nl> wrote:
>
> Inform doesn't provide undo: that's done by the interpreter, which
> could certainly provide multiple-level undo if it wanted to. I
> suspect interpreters didn't, simply because of memory limitations, but
> with the small save files now used (O(2--5k)) that looks a bit silly.
> Presumably we'll see more and more interpreters supporting
> multiple-level undo. But it's nothing to do with Inform (although
> perhaps a mechanism could be added to allow Inform to control the
> feature, so you could say "undo 3" to undo three turns or something).
Zip 2000 provides multiple undo (not a hot-key), but this feature is
only available for Infocom games. Apparently the Inform library won't
allow it, but could be made to do so. Each undo allowed takes approx.
30K of memory. The length of save files isn't affected.
Jools
--
Carl Edman
Dan Shiovitz wrote:
> Carl Edman <ced...@lynx.ps.uci.edu> wrote:
> >Please forgive my verbosity on this subject, but I've thought about it
> >and believe that a similar solution can be applied to all puzzles which
> >would be "spoiled" by undo. The basic idea is to keep all information
> >which is unknowable to the player, undetermined by the interpreter.
>
> For instance (Curses spoiler)
>
> To defuse the bomb, you need to pull the wires out in the right order.
> To figure out the right order, you need to look at the scarf. What if
> the player fails to look at the scarf, but uses undo to try all
> possibilities and solves it that way?
That is a good question. I take it that the sequence of wires has no
deeper meaning and changes randomly from game to game ? In that case it
would be entirely fair to initialize the wire sequence to 'undetermined'
and only randomly generate it when you actually look at the scarf. If
the sequence is undetermined, any pulls on the wires results in
detonation.
As long as there is load/save/undo, all players have infinite luck. Any
puzzle which is soluble by luck becomes an optional puzzle. If you want
to have a mandatory puzzle, you have to force the player to be unlucky.
> I'm pretty sure he was only speaking about the undo which Frotz does,
> overriding the author's control over the game. I know if I was programming
> in Inform, I'd be annoyed by it. (Of course, since I only play, I love it.
> But I'd rather just have the language handle it better.)
I agree. Undo should be a command like save and load. But if an author
feels the need to override this command to do anything other than add
cute messages, he probably hasn't thought through the problem
sufficiently.
Carl Edman
Andrew Plotkin
Carl Edman (ced...@lynx.ps.uci.edu) wrote:
> As long as there is load/save/undo, all players have infinite luck. Any
> puzzle which is soluble by luck becomes an optional puzzle. If you want
> to have a mandatory puzzle, you have to force the player to be unlucky.
> > I'm pretty sure he was only speaking about the undo which Frotz does,
> > overriding the author's control over the game. I know if I was programming
> > in Inform, I'd be annoyed by it. (Of course, since I only play, I love it.
> > But I'd rather just have the language handle it better.)
> I agree. Undo should be a command like save and load. But if an author
> feels the need to override this command to do anything other than add
> cute messages, he probably hasn't thought through the problem
> sufficiently.
I understand your point, and mostly agree with it. However, one might get
to the point where you're making the player *too blatantly* unlucky. I
wouldn't want to make the effect too artificial. (For example, if the
number of choices is small.) So I might choose to override "undo" anyway.
Or design the puzzle so that there are lots of choices. This is all
hypothetical; I've never overridden "undo" in a game.
And yes, undo is a command just like save and restore. *If* I wrote a game
that overrode undo, I would override save and restore in the same way.
Julian Arnold
> row. If you hack the library *and* run it on a multiple-undo-supporting
> interpreter, your game will support multiple undo.
I've got to say though, I don't see any great need to undo more than one
turn. If I undo it is for one of four reasons:
a) I've made a factual error. For example, I've taken the piano
wire when I meant to take the bishop's mitre.
b) I've done something wrong, and wish I hadn't.
c) I've done something wrong, and died.
d) Time is critical, and I want to steal a look, etc. Ie, I'm
cheating.
Of these, multiple undo would be possibly useful in cases b) and c)
(which are, really, the same). OK, if I realise on turn 20 I made a
boo-boo a dozen turns ago, I restore (I keep lots of save files). Who
can remember their last dozen moves? (yes, I'm sure lots of you can,
don't post :)
Simply, if I want to retract more than one turn I restore, and start
with a clean slate.
That said, if multiple undo is possible, and can be turned off so it
doesn't usurp authorial control, by all means, have it. I just think
it's overrated.
Jools
--
Andrew Plotkin
Julian Arnold (jo...@arnod.demon.co.uk) wrote:
> > Inform doesn't provide undo: that's done by the interpreter, which
> > could certainly provide multiple-level undo if it wanted to.
>
> only available for Infocom games. Apparently the Inform library won't
> allow it, but could be made to do so.
Right. The library sets a flag which prevents you from undoing twice in a
row. If you hack the library *and* run it on a multiple-undo-supporting
interpreter, your game will support multiple undo.
--Z
Mark J Tilford
Mark J. Tilford
mjti...@artsci.wustl.edu
On Thu, 29 Aug 1996, Carl Edman wrote:
> Andrew Plotkin wrote:
> > aul...@koala.scott.net wrote:
> > > >> In Inform, is there any way I can turn off the "undo" feature in my
> > > >> game?
> > >
> > > You might not want to bother with this, because the feature can be (and
> > > has been) implemented in Z-code interpreters, anyway. I'll always be able
> > > to Alt-U in Frotz, no matter what your code says.
>
<discussion of the 12-cube puzzle in Spellbreaker snipped>
What about the three door problem in Zork Zero? The writers wanted the
player to work out which door led to the Wishyfoo. (note that they forgot
to turn off undo in the Prevaricon and Veritas rooms, so if you choose
wrong you could undo.)
Dan Shiovitz
In article <ant30225...@arnod.demon.co.uk>,
Julian Arnold <jo...@arnod.demon.co.uk> wrote:
[..]
>I've got to say though, I don't see any great need to undo more than one
>turn. If I undo it is for one of four reasons:
> a) I've made a factual error. For example, I've taken the piano
> wire when I meant to take the bishop's mitre.
> b) I've done something wrong, and wish I hadn't.
> c) I've done something wrong, and died.
> d) Time is critical, and I want to steal a look, etc. Ie, I'm
> cheating.
How about
e) I need to take a one-way journey someplace, and then do something when
I get there, or else I'm stuck.
For example, in Path to Fortune, when I was trying to defeat the dark elven
bowman, I had to get an idea on how to do it, walk into the room, and then
try the idea. If the idea didn't work, I was stuck, because you die if
you walk out of the room. All I wanted was *two* turn undo :)
>Jools
Ross Raszewski
And you'd get a lot of people who wouldn't want to play it.
(it is, perhaps, apostate here that any override doen to Undo in inform
would (hypothetically) blitz Fortz's hot key, as well, as the frotz hot
keys seem to work more like macros.
Ross Raszewski
Andrew Plotkin wrote:
>
> aul...@koala.scott.net wrote:
> > >> In Inform, is there any way I can turn off the "undo" feature in my
> > >> game?
> >
> > You might not want to bother with this, because the feature can be (and
> > has been) implemented in Z-code interpreters, anyway. I'll always be able
> > to Alt-U in Frotz, no matter what your code says.
>
> a puzzle like the 12-cubes one in Spellbreaker? Should I just add a note
> saying "This game does not work correctly in Frotz. Use a different
> interpreter."?
>
> comments about "save" and "restore"?
>
> make it clear that a this undo feature is a *cheat* feature. It's like a
> interpreter feature to examine or set object attributes. I don't object to
> writing interpreters that do this, but their users should know that using
> the cheat keys may screw up game play.)
>
>
But by this logic, shouldn't the writers of Inform games also tell
people that undo is a "cheat feature". I mean, save and restore is a
"cheat feature" in some senses.
Carl Edman
Mark J Tilford wrote:
> What about the three door problem in Zork Zero? The writers wanted the
> player to work out which door led to the Wishyfoo. (note that they forgot
> to turn off undo in the Prevaricon and Veritas rooms, so if you choose
> wrong you could undo.)
Sorry, but I can't comment because I don't remember that puzzle. I did
solve Zork Zero when it first came out, but that was a long time ago.
Come to think of it, I solved Spellbreaker when it first came out too
and that was even earlier, yet I have not forgotten many puzzles from
it. Does that mean that Spellbreaker is the better game ? I'd say so.
If the puzzle is of this type, you can't do much to fix it.
You see three doors. On the first door it says "Wrong One"[in pig
latin], on the second
one it says "Right One"[also in pig latin] and on the third one it says
"Also Wrong"[in p.l.].
There is just no way to tell if the player figured it out or didn't.
Much better if the door description were in secret ink and you needed to
apply a special device to read them. Unless the device was applied the
doors would always lead to the wrong room.
Carl Edman
Marnix Klooster
Andrew Plotkin (erky...@netcom.com) wrote:
> Julian Arnold (jo...@arnod.demon.co.uk) wrote:
> > > Inform doesn't provide undo: that's done by the interpreter, which
> > > could certainly provide multiple-level undo if it wanted to.
> >
> > Zip 2000 provides multiple undo (not a hot-key), but this feature is
> > only available for Infocom games. Apparently the Inform library won't
> > allow it, but could be made to do so.
> Right. The library sets a flag which prevents you from undoing twice in a
> row. If you hack the library *and* run it on a multiple-undo-supporting
> interpreter, your game will support multiple undo.
This is definitely *not true*. The limitation to single undo is part
of the design of the Z-machine. (Roughly speaking, the Z-machine is
the game file format that Infocom used for their interactive fiction.)
Since Inform produces game files in Z-machine format, this limitation
is inherent to all Inform games. No library hacking can help you
overcome this. That is the reason for the above-mentioned library
flag: it protects the programmer from trying to perform undo
(technically, the RESTORE_UNDO instruction) twice in a row; what
happens when you try this is undefined, i.e. different interpreters
might react differently, or even crash.
About Zip 2000: I suspect that Kevin Bracey, the author of this
interpreter, has silently extended the Z-machine, so that multiple
RESTORE_UNDO instructions *do* work. Kevin, can you confirm this?
(And maybe post a description on the Z-machine mailing list?) The
multiple undo facility in Frotz is independent of the Z-machine's undo
mechanism. This makes it work on all Infocom & Inform games, even
pre-version-5 ones (which don't have the SAVE_UNDO and RESTORE_UNDO
instructions).
Summarizing: if a game is to understand things like "undo 3", apart
from library changes one needs to change the Z-machine specification,
and use an interpreter that understands this extension. Zip 2000
silently seems to have done the latter.
> --Z
Groetjes,
<><
Marnix
--
Marnix Klooster
kloo...@dutiba.twi.tudelft.nl // mar...@worldonline.nl
Marnix Klooster
Andrew Plotkin (erky...@netcom.com) wrote:
> aul...@koala.scott.net wrote:
> > >> In Inform, is there any way I can turn off the "undo" feature in my
> > >> game?
> >
> > You might not want to bother with this, because the feature can be (and
> > has been) implemented in Z-code interpreters, anyway. I'll always be able
> > to Alt-U in Frotz, no matter what your code says.
> This is a flaw in Frotz, as far as I'm concerned. What if I want to write
> a puzzle like the 12-cubes one in Spellbreaker? Should I just add a note
> saying "This game does not work correctly in Frotz. Use a different
> interpreter."?
> What if I just want to add cute comments about "undo", a la Floyd's cute
> comments about "save" and "restore"?
> (Yes, I'm being sarcastic. But I do think that such interpreters should
> make it clear that a this undo feature is a *cheat* feature. It's like a
> interpreter feature to examine or set object attributes. I don't object to
> writing interpreters that do this, but their users should know that using
> the cheat keys may screw up game play.)
As far as I can see, using Frotz-like undo is not cheating -- it's
rather like turning back to a previous page in a book. It doesn't
give you new information. The only thing it does is to remove
undo-control from the programmer.
Another way to see that Frotz-like undo gives you nothing that
couldn't be done before: the same effect can be achieved by restarting
the game, and execute all except the last few commands. Which is
already possible using the SCRIPT command, a decent editor, and an
interpreter capable of replaying scripts; or (in theory) simply by
restarting the game and retyping all commands.
All Frotz-like undo does it to give the player a tool to peruse a work
of I-F not just linearly, by typing one command after the other, but
tree-like, by trying different lines of action. Without the hassle of
typing SAVE, RESTORE, and UNDO every time.
Actually, there are two ways in which Frotz undo can be improved: (1)
make the `undo hotkey' also restore the state of the screen; and (2)
add a `redo hotkey' that can be used to redo a move that was undone.
In effect, this adds a kind of scrolling ability. (This might also
solve the "game prints message only once" problem that someone
recently posted about.)
Using such features is not cheating, they are simply convenient.
Especially for cruel games.
Andrew Plotkin
Marnix Klooster (mar...@worldonline.nl) wrote:
> > Right. The library sets a flag which prevents you from undoing twice in a
> > row. If you hack the library *and* run it on a multiple-undo-supporting
> > interpreter, your game will support multiple undo.
> This is definitely *not true*. The limitation to single undo is part
> of the design of the Z-machine. [...]
> About Zip 2000: I suspect that Kevin Bracey, the author of this
> interpreter, has silently extended the Z-machine, so that multiple
> RESTORE_UNDO instructions *do* work.
I ain't seeing what you're claiming. (I'm looking at the 0.2 spec
document.) @save_undo "saves the game into a cache of memory held by the
interpreter." @restore_undo "restores the state saved to memory by
@save_undo... The behavior of @restore_undo is unspecified if no
@save_undo has previously occurred." But it doesn't say that the cache is
invalidated after the @restore_undo completes. If the cache is reloaded
with an earlier state, such that a further @restore_undo will restore
*that* and return a success value, is this contrary to the spec?
If this is an extension to the Z-machine, then I propose it.
Specifically: It is up to the interpreter whether a @restore_undo should
succeed or fail; the game should just try it and test the return value.
Exception: the interpreter should always have @restore_undo fail if no
@save_undo has been executed; and the game should never try this, since
some interpreters may explode.
But honestly I think this is the way interpreters behave *now*. Both Zip
2000 and the single-undo-supporting interpreters.
(PS: When I say "restore returns a success value", of course I mean that
control passes back to the "save" statement, which returns 2.)
Dylan O'Donnell
mar...@worldonline.nl (Marnix Klooster) wrote:
>Another way to see that Frotz-like undo gives you nothing that
>couldn't be done before: the same effect can be achieved by restarting
>the game, and execute all except the last few commands. Which is
>already possible using the SCRIPT command, a decent editor, and an
>interpreter capable of replaying scripts; or (in theory) simply by
>restarting the game and retyping all commands.
Not true, in any game which includes a randomiser. Undoing up _until_
the last random choice was made seems perfectly legitimate to me;
undoing to _before_ it, and trying again and hoping it'll go better
this time, defeats the point of having the randomiser in the first
place (and is thus going against the intentions of the game author)
--
Dylan O'Donnell (dyl...@demon.net)
Demon Internet Ltd, Southend slave deck annexe
http://www.vy.com/psmith.html
Aka Psmith (elsewhere). Badger? *urf*
Greg Falcon
erky...@netcom.com (Andrew Plotkin) wrote:
>Carl Edman (ced...@lynx.ps.uci.edu) wrote:
>> I agree. Undo should be a command like save and load. But if an author
>> feels the need to override this command to do anything other than add
>> cute messages, he probably hasn't thought through the problem
>> sufficiently.
>And yes, undo is a command just like save and restore. *If* I wrote a game
>that overrode undo, I would override save and restore in the same way.
Somehow, it bugs me that Frotz would allow its own Undo. I agree with
the comment made somewhere in this thread (I don't remember where)
that using an interpreter to allow UNDO even when it is overridden is
cheating. I understand Carl's point that overriding UNDO shouldn't be
necessicary in a well thought out puzzle, and agree up to a point. I
don't think, however, that because a puzzle isn't well though out,
using an interpreter-level undo is in the least bit honest.
For example, from _Beyond Zork_:
----
>e
Mud Flats
The eldritch vapor coalesces out of the surrounding mist.
>attack vapor
[with the rusty dagger]
You strike at the eldritch vapor with the rusty dagger, but miss.
The eldritch vapor giggles insanely. "Nyeah, nyeah!"
>[**Hit interpreter-level undo hot-key here**]
Mud Flats
>attack vapor
[with the rusty dagger]
Your rusty dagger seriously wounds the eldritch vapor.
The eldritch vapor whispers an obscene secret in your ear. "Boo!"
----
The programmers wanted UNDO to be blocked off from the players like
so:
>undo
You begin to mumble the Spell of Undoing, but the sight of the
eldritch vapor makes your mind wander.
>save
You begin to mumble the Spell of Saving, but the sight of the eldritch
vapor makes your mind wander.
A hot key that allows for unconditional UNDOing takes an extreme
amount of power away from the game designer. There may be a place for
interpreter-level undo. However, the player should not be fooled for
one moment to think that using it to override any UNDO blocks in the
game is cheating, IMHO.
If the player doesn't mind "cheating", however, I have absolutely no
problem with this. In fact, I cheat. (I like hex-editing the Beyond
Zork save file and giving myself 99 of every attribute, or using
in-game bugs to make tens of thousands of zorkmids.) But let's call a
spade a spade. An interpreter-level undo used on modern games is a
cheating tool.
Just my $0.02.
That wasn't too bad (for a second post),
Greg Falcon
Trevor Barrie
mar...@worldonline.nl (Marnix Klooster) wrote:
>> Right. The library sets a flag which prevents you from undoing twice in a
>> row. If you hack the library *and* run it on a multiple-undo-supporting
>> interpreter, your game will support multiple undo.
>This is definitely *not true*. The limitation to single undo is part
>of the design of the Z-machine.
I find this a little hard to believe, considering how full-featured Inform
is supposed to be. You can write Tetris on it, but you can't store two or
more sets of changes to the game state in memory?
Andrew Plotkin
Z-machine undo doesn't work by storing changes in memory. It works by
signalling the interpreter to copy *all* of memory to an external buffer
-- external to the Z-machine, that is. The Z-machine can't get at it,
except by the inverse signal, which tells the interpreter to copy the data
back.
So the capacity of undo isn't really reprogrammable within the machine;
it depends on the behavior of those two signals, as defined in the
Z-machine specification. If you write an interpreter that acts not in
accordance with those definitions, your interpreter has diverged from the
standard.
See?
(But see my previous post, where in a sudden flurry of nitpicking I argue
that Zip 2000 has not diverged from the standard in implementing multiple
undo.)
Molson Ice
I don't see why everyone's so riled up about potential
cheating. What it comes down to is that you paid for the game.
You got it for no other reason than your own entertainment. If
you want to cheat and think you'll enjoy it more that way then
go ahead. If you think it's wrong then don't do it. How is
this type of cheating any different than hint books which
outright give you all the answers anyway.
Admititdly, I have used these books and later wish I hadn't for
some puzzles (others are so difficult that I would do it again
if I had the chance) but it was my choice to do so.
Mike Taylor
90% Nigel
There will be an Answer Let it Be
Greg Falcon
erky...@netcom.com (Andrew Plotkin) wrote:
>Marnix Klooster (mar...@worldonline.nl) wrote:
>> > Right. The library sets a flag which prevents you from undoing twice in a
>> > row. If you hack the library *and* run it on a multiple-undo-supporting
>> > interpreter, your game will support multiple undo.
>> This is definitely *not true*. The limitation to single undo is part
>> of the design of the Z-machine. [...]
>> About Zip 2000: I suspect that Kevin Bracey, the author of this
>> interpreter, has silently extended the Z-machine, so that multiple
>> RESTORE_UNDO instructions *do* work.
>I ain't seeing what you're claiming. (I'm looking at the 0.2 spec
>document.) @save_undo "saves the game into a cache of memory held by the
>interpreter." @restore_undo "restores the state saved to memory by
>@save_undo... The behavior of @restore_undo is unspecified if no
>@save_undo has previously occurred." But it doesn't say that the cache is
>invalidated after the @restore_undo completes. If the cache is reloaded
>with an earlier state, such that a further @restore_undo will restore
>*that* and return a success value, is this contrary to the spec?
I'm looking at the 0.2 spec document, too. Sorry to disagree, but
Marnix Klooster is right.
From the 0.2 spec:
6.1.1.2 An internal saved game for "undo" purposes (if there is one)
is not part of the state of play. This is important: if a saved
game file also contained the internal saved game at the time of
saving, it would be impossible to undo the act of restoration. It
also prevents internal saved games from growing larger and larger as
they include their predecessors.
>If this is an extension to the Z-machine, then I propose it.
I don't know. The point about being unable to UNDO a RESTORE is worth
thinking about.
Greg
-----
C:\INFORM>inform thid.inf
Unix Inform 5.5 (v1502/a)
line 3841: Fatal Error: Couldn't open output file "thid.inf.z5"
C:\INFORM>_
Greg Falcon
Ross Raszewski <rras...@skipjack.bluecrab.org> wrote:
>(it is, perhaps, apostate here that any override doen to Undo in inform
>would (hypothetically) blitz Fortz's hot key, as well, as the frotz hot
>keys seem to work more like macros.
No, Frotz's undo "macro" actually stores the game states itself. In
Frotz, you can UNDO the game even if the designer chose to disable it.
Plus, in Frotz, you can undo more than one move.
Andrew Plotkin
Greg Falcon (professo...@pnx.com) wrote:
> erky...@netcom.com (Andrew Plotkin) wrote:
> >I ain't seeing what you're claiming. (I'm looking at the 0.2 spec
> >document.) @save_undo "saves the game into a cache of memory held by the
> >interpreter." @restore_undo "restores the state saved to memory by
> >@save_undo... The behavior of @restore_undo is unspecified if no
> >@save_undo has previously occurred." But it doesn't say that the cache is
> >invalidated after the @restore_undo completes. If the cache is reloaded
> >with an earlier state, such that a further @restore_undo will restore
> >*that* and return a success value, is this contrary to the spec?
> From the 0.2 spec:
> 6.1.1.2 An internal saved game for "undo" purposes (if there is one)
> is not part of the state of play. This is important: if a saved
> game file also contained the internal saved game at the time of
> saving, it would be impossible to undo the act of restoration. It
> also prevents internal saved games from growing larger and larger as
> they include their predecessors.
So? This does not say that the interpreter cannot put additional
information alongside that saved-game state. The interpreter always has
gobs of private information.
> >If this is an extension to the Z-machine, then I propose it.
> I don't know. The point about being unable to UNDO a RESTORE is worth
> thinking about.
I did not propose that the Z-machine spec be changed to *require*
multiple undo. I said that the Z-machine should leave it up to the
interpreter to decide when an undo request is fulfillable, and when it
isn't. And that it test this using the already-defined mechanism of the
return code of the @restore_undo opcode.
And I still think the Z-spec is already compatible with this philosophy.
Trevor Barrie
erky...@netcom.com (Andrew Plotkin) wrote:
>> I find this a little hard to believe, considering how full-featured Inform
>> is supposed to be. You can write Tetris on it, but you can't store two or
>> more sets of changes to the game state in memory?
>Z-machine undo doesn't work by storing changes in memory. It works by
>signalling the interpreter to copy *all* of memory to an external buffer
>-- external to the Z-machine, that is. The Z-machine can't get at it,
>except by the inverse signal, which tells the interpreter to copy the data
>back.
So if you need multiple-level undo, you write your own code which stores two
or more sets of changes to the game state somewhere accessible to the
Z-machine, and then recovers it if necessary.
Marnix Klooster
dyl...@demon.net (Dylan O'Donnell) wrote:
> mar...@worldonline.nl (Marnix Klooster) wrote:
> >Another way to see that Frotz-like undo gives you nothing that
> >couldn't be done before: the same effect can be achieved by restarting
> >the game, and execute all except the last few commands. Which is
> >already possible using the SCRIPT command, a decent editor, and an
> >interpreter capable of replaying scripts; or (in theory) simply by
> >restarting the game and retyping all commands.
> Not true, in any game which includes a randomiser.
You're right here, of course. Slip of the mind. However, in most
Inform/Infocom games you *can* emulate the effect of Frotz-like undo
by SAVEing often (or even every move). There are only a few games
that forbid SAVE/RESTORE/UNDO in certain places, to prevent solving a
puzzle by luck.
> Undoing up _until_
> the last random choice was made seems perfectly legitimate to me;
> undoing to _before_ it, and trying again and hoping it'll go better
> this time, defeats the point of having the randomiser in the first
> place (and is thus going against the intentions of the game author)
Most of the time, I don't know what the intentions of the author are:
she should make them known in the game. One way is to simply say "You
will spoil this game when using Frotz-like undo." Another is to
design puzzles well, as others have argued forcefully in this and
other threads: the game must be (reasonably) sure that the player has
indeed solved a puzzle (as opposed to having guessed) before giving
out the reward for it. This way the author doesn't have to be afraid
for undo, because it won't make the player more lucky.
In the Inform case, yet a third way is to modify the Inform library so
that the game can control when the SAVE_UNDO Z-machine instruction is
executed. If this instruction is not executed, even the Frotz undo
hotkey can't help -- except in V1-4 games, where it might be
considered a cheat feature.
As an aside, I believe I saw a TADS example long ago that solved all
this in a very elegant way: if you did "UNDO" after making a wrong
guess, things were randomized again!
* * *
In a Phone Booth
There's a phone here. And a small note, too. It says, "Try dialling
1-800-UNDO, access code 65535."
>DIAL 1-800-UNDO
A metallic voice says, "Did you make a mistake? Have you accidentally
hurt a friend? Or maybe a grue had you for breakfast? Don't worry --
dial your personal access code and you'll forget all about it. And
the world'll forget it, too. In fact, *we*'ll even forget that you
called." --beep--
>DIAL 12345
The voice continues: "That's not a valid access code. Hmmm... Say,
who is this, anyway? Hello? Anybody there?"
*** The world has forgotten that you even existed ***
Would you like to RESTART, RESTORE, UNDO, or QUIT?
>UNDO
Welcome back!
In a Phone Booth
There is a phone here. And a small note, too. It says, "Try dialling
1-800-UNDO, access code 12345."
Something tells you this is not the world you used to live in.
>DIAL 12345
The voice continues: "Correct. Please state the mistake you want to
correct."
>...
* * *
Similar solutions may be possible in Inform, but this requires
changing and extending the library. I'd suggest adding new actions
##Restored and ##Undone which are executed after RESTORE and
RESTORE_UNDO instructions. Anyone willing to try his/her hand at
this?
> --
> Dylan O'Donnell (dyl...@demon.net)
> Demon Internet Ltd, Southend slave deck annexe
> http://www.vy.com/psmith.html
> Aka Psmith (elsewhere). Badger? *urf*
Groetjes,
Greg Ewing
Trevor Barrie wrote:
>
> You can write Tetris on it, but you can't store two or
> more sets of changes to the game state in memory?
If you can find enough room in the 64K writeable
address space, you could do it in z-code.
But usually undoing is left up to the interpreter,
which can store a copy of the whole 64K somewhere
else, or multiple copies if it wants.
There is an official "undo" z-code for telling
the interpreter to do this, but it's defined as
a single-level undo. If the interpreter does
otherwise with this opcode, it's not implementing
the z-machine according to specification. In that
sense, the z-machine (as distinct from the interpreter)
is limited to 1-level undo.
Greg
Greg Ewing
Greg Falcon wrote:
>
> I don't know. The point about being unable to UNDO a RESTORE is worth
> thinking about.
If there is to be multiple undo, I think the undo
state chain *should* be saved with SAVE and restored
with RESTORE.
Reason: Suppose I have fought my way through the
army of purple hamsters and reached the suspension
bridge. I get half way across, notice it's time
for bed, and SAVE.
Next evening I RESTORE, take one step, the
bridge collapses, and I die. I decide it wasn't
such a good idea to enter the bridge, and want
to undo a few turns. If the undo state hasn't
been saved, I can't.
The point is that there are two different uses
of SAVE: (1) to suspend a game so you can come
back to it later; (2) to save a previous state
for mass-undoing purposes. Not saving the undo state
messes up (1). Saving it makes RESTORE un-undoable,
but this is no great loss: if you want to make
a RESTORE undoable, SAVE before the RESTORE.
With only single-level undo, the problem is less
likely to arise, since you're not so likely to
want to save immediately after something you
may want to undo. But it could happen, if the
reason you want to undo is more subtle than
death, and you only notice after restoring
the next day, but before you've made another
move.
Greg (the other one)
Matthew Miller
In rec.arts.int-fiction, Carl Edman (ced...@lynx.ps.uci.edu) writes:
: Mark J Tilford wrote:
: > What about the three door problem in Zork Zero? The writers wanted the
: > player to work out which door led to the Wishyfoo. (note that they forgot
: > to turn off undo in the Prevaricon and Veritas rooms, so if you choose
: > wrong you could undo.)
: Sorry, but I can't comment because I don't remember that puzzle.
: You see three doors. On the first door it says "Wrong One"[in pig
: latin], on the second
: one it says "Right One"[also in pig latin] and on the third one it says
: "Also Wrong"[in p.l.].
Oday ouyay otnay ikelay Igpay Atinlay? :)
If this is the one I'm thinking of, it's really one door with a
hallway that leads to three different places depending on how you solve a
puzzle nearby. A Tower of Hanoi (though they call it something else)
where you have to move all the disks to one of three towers to get at one
of the three places.
(Incidentally, Towers of Hanoi are probably easier to solve for
programmers than for the general run of humankind, since you can easily
solve one using a simple, standard algorithm.)
This is rather nice, I think, since, even though it is a `classic'
(read: really really unoriginal) puzzle, like a lot in Zork Zero, Meretzky
thought to add the extra touch of the different towers causing different
exits.
--
Matthew Miller -- rmi...@infinet.com
Carl Muckenhoupt
rmi...@infinet.com (Matthew Miller) writes:
>In rec.arts.int-fiction, Carl Edman (ced...@lynx.ps.uci.edu) writes:
>: Mark J Tilford wrote:
>: > What about the three door problem in Zork Zero? The writers wanted the
>: > player to work out which door led to the Wishyfoo. (note that they forgot
>: > to turn off undo in the Prevaricon and Veritas rooms, so if you choose
>: > wrong you could undo.)
>: Sorry, but I can't comment because I don't remember that puzzle.
>: If the puzzle is of this type, you can't do much to fix it:
>: You see three doors. On the first door it says "Wrong One"[in pig
>: latin], on the second
>: one it says "Right One"[also in pig latin] and on the third one it says
>: "Also Wrong"[in p.l.].
> Oday ouyay otnay ikelay Igpay Atinlay? :)
> If this is the one I'm thinking of, it's really one door with a
>hallway that leads to three different places depending on how you solve a
>puzzle nearby. A Tower of Hanoi (though they call it something else)
>where you have to move all the disks to one of three towers to get at one
>of the three places.
Nope. It's the knight-knave puzzle (although it doesn't use those terms.)
Three tribes, one of people who always tell the truth, one of people who
always lie, one of people who alternately tell the truth and lie. Three
doors, one to each tribe. Each door has a two-sentence inscription on it
written by a member of the appropriate tribe. You want to visit the tribe
where they won't kill you immediately. I can't describe it any more fully,
because the actual contents of the inscriptions were generated randomly
(but always sufficient to solve the puzzle).
> (Incidentally, Towers of Hanoi are probably easier to solve for
>programmers than for the general run of humankind, since you can easily
>solve one using a simple, standard algorithm.)
And of course it's another example of the computer's revenge, making us
go through exactly the same labors as they are put through by thousands
of CS freshmen every year.
--
Carl Muckenhoupt | Text Adventures are not dead!
b...@tiac.net | Read rec.[arts|games].int-fiction to see
http://www.tiac.net/users/baf | what you're missing!
Andrew Plotkin
> >> I find this a little hard to believe, considering how full-featured Inform
> >> is supposed to be. You can write Tetris on it, but you can't store two or
> >> more sets of changes to the game state in memory?
> >Z-machine undo doesn't work by storing changes in memory. It works by
> >signalling the interpreter to copy *all* of memory to an external buffer
> >-- external to the Z-machine, that is. The Z-machine can't get at it,
> >except by the inverse signal, which tells the interpreter to copy the data
> >back.
> So if you need multiple-level undo, you write your own code which stores two
> or more sets of changes to the game state somewhere accessible to the
> Z-machine, and then recovers it if necessary.
The "game state" is a snapshot of the Z-machine's memory. The only place
available to write in is the Z-machine's memory. I trust the problems
become apparent.
Yes, you can optimize matters, but you're still using up huge extra
chunks of your RAM (of which you only have 64k) to add this feature,
which is supposed to be an interpreter-level feature anyway.
Carl D. Cravens
On 13 Sep 1996 02:42:06 GMT, rmi...@infinet.com (Matthew Miller) wrote:
> (Incidentally, Towers of Hanoi are probably easier to solve for
>programmers than for the general run of humankind, since you can easily
>solve one using a simple, standard algorithm.)
The recursive solution is painful, but fast. The solution for humans to
use is...
Consider the two end pegs to be adjacent, as if the pegs were in a
circle. Peg 1 is to the right of peg 3, etc. Then follow these simple
rules. Even numbered disks move right, odd numbered disks move left,
always move the largest disk which can be moved. Works for any number
of disks.
--
Carl (rave...@southwind.net)
If I want your opinion, I'll take you out of my killfile.
Russell Wain Glasser
>> (Incidentally, Towers of Hanoi are probably easier to solve for
>>programmers than for the general run of humankind, since you can
easily
>>solve one using a simple, standard algorithm.)
>
>The recursive solution is painful, but fast. The solution for humans
to
>use is...
**SHAMELESS PLUG ALERT**
For a better implemented version of the Tower of Hanoi than the one
that appeared in Zork Zero, visit my web site
http://sdcc8.ucsd.edu/~rglasser/hanoi.zip
for a 3d Windows version written in Visual C++ along with 3d Studio.
Not only does it look really cool, but it also has an autosolve feature
which lets you cheat one move at a time. (Been writing it as a test for
my understanding of Foundation Classes.)
Let me know if it doesn't work, I haven't tried it on different
computer yet...
John Francis
> >programmers than for the general run of humankind, since you can easily
> >solve one using a simple, standard algorithm.)
>
> The recursive solution is painful, but fast. The solution for humans to
> use is...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> circle. Peg 1 is to the right of peg 3, etc. Then follow these simple
> rules. Even numbered disks move right, odd numbered disks move left,
> always move the largest disk which can be moved. Works for any number
> of disks.
An alternative formulation is:
On odd-numbered turns, move the smallest disk one peg to the right.
On even-numbered turns, make the only possible legal move that moves
a disk other than the smallest disk.
John Holder
Russell Wain Glasser (rgla...@ix.netcom.com) wrote:
: For a better implemented version of the Tower of Hanoi than the one
> FOLLOW URL
Sorry, the requested URL was not found on that server.
> WHY NOT?
I don't know, I'm just a dumb parser. Ask the implementor...
--
John Holder (jho...@frii.com) http://www.frii.com/~jholder/
UNIX Specialist, Paranet Inc., Denver, Colorado, USA, Earth
Death is just God's way of dropping carrier detect...
John Holder
: For a better implemented version of the Tower of Hanoi than the one
: that appeared in Zork Zero, visit my web site
: http://sdcc8.ucsd.edu/~rglasser/hanoi.zip
: for a 3d Windows version written in Visual C++ along with 3d Studio.
: Not only does it look really cool, but it also has an autosolve feature
: which lets you cheat one move at a time. (Been writing it as a test for
: my understanding of Foundation Classes.)
: Let me know if it doesn't work, I haven't tried it on different
: computer yet...
You went to LAHS? Dang! So did I! In fact, the first time I played
Adventure was on a PDP11 at LANL on a family day with my Dad back in `77-79
sometime.
Just another soul that glows in the dark...
Russell Wain Glasser
In <51p8v5$n...@europa.frii.com> jho...@frii.com (John Holder) writes:
>
>Russell Wain Glasser (rgla...@ix.netcom.com) wrote:
>: For a better implemented version of the Tower of Hanoi than the one
>: that appeared in Zork Zero, visit my web site
>: http://sdcc8.ucsd.edu/~rglasser/hanoi.zip
>
>
>Sorry, the requested URL was not found on that server.
>
>> WHY NOT?
>
>I don't know, I'm just a dumb parser. Ask the implementor...
>
>IMPLEMENTOR, WHERE IS YOUR FRIGGING WEB SITE?
Russell replies, "My school has been hassling me about my account
and the associated web site for a few days. I can't access my own web
page either, nor can I read my mail. I'm going to be bugging the
administrator about it when I get the chance, so try the link again
soon. I've recently added sound effects, magically floating discs, and
more extensive game options."
>THANK IMPLEMENTOR
"You're welcome!"
>KILL UCSD.EDU
You have done the implementor a big favor. Out of gratitude, he
awards you fifty points.
Matthew Miller
In rec.arts.int-fiction, John Holder (jho...@frii.com) writes:
: Russell Wain Glasser (rgla...@ix.netcom.com) wrote:
: : For a better implemented version of the Tower of Hanoi than the one
: : that appeared in Zork Zero, visit my web site
: : http://sdcc8.ucsd.edu/~rglasser/hanoi.zip
Nope, it's there -- are you *sure* you typed in the url correctly?
Russell Wain Glasser
>: : For a better implemented version of the Tower of Hanoi than
the one
>: : that appeared in Zork Zero, visit my web site
>: : http://sdcc8.ucsd.edu/~rglasser/hanoi.zip
>: Sorry, the requested URL was not found on that server.
>
>Nope, it's there -- are you *sure* you typed in the url correctly?
>
>--
>Matthew Miller -- rmi...@infinet.com
Don't blame him, my web address comes and goes. I lose access to
my account if I use up my allotted hours each week, and outsiders also
lose access to my page. Unfortunately, what's really screwing me up is
that I have a web page devoted to insulting the Amway corporation, and
that gets hundreds of hits per week. I have a feeling they're eating
up my on-line time.
Anyway... the Tower of Hanoi program is still undergoing surgery,
including a working 256 color version (right now it only works in high
color), scorekeeping, and saving your preferred options. If you liked
it, keep checking because it's getting better.
John Holder
Matthew Miller (rmi...@infinet.com) wrote:
: In rec.arts.int-fiction, John Holder (jho...@frii.com) writes:
: : Russell Wain Glasser (rgla...@ix.netcom.com) wrote:
: : : that appeared in Zork Zero, visit my web site
: : : http://sdcc8.ucsd.edu/~rglasser/hanoi.zip
: : Sorry, the requested URL was not found on that server.
: Nope, it's there -- are you *sure* you typed in the url correctly?
Sure it's there NOW, but it wasn't a week ago when the post hit my server.
I got email from Mr. Glasser explaining his woes of his web site, and
apparantly there are all worked out.
Wheres a rusty knife when you need one... ;)